Two micro-optimizations are done in this patch:
1. We know exactly how these placeholders are built in the makeHolder()
method. In »<!--IWLINK'" 1-->« it's guaranteed to be a single number
and in »<!--LINK'" 1:2-->« it's two numbers.
The most extreme synthetic micro benchmark I did cuts the runtime of
these regular expressions down to about 25%. It won't make much of a
difference in real-world scenarios but is still worth it, I believe.
It also makes the code more specific and less confusing (see below).
2. We don't need to use the full string »<!--LINK'" 1:2-->« as array
key when the only thing that matters is the part »1:2«. Note the same
is done just a few lines below in the replaceInterwiki() method.
This code does have outstanding test coverage via all the parser tests,
I believe. Any change here that doesn't make a test fail should be safe.
Note the unit tests have been written many years later via I2c12cc7,
using "dummy" strings and such instead of the expected numeric
namespace and link ids. Most of this is already fixed via previous
patches. The last mistake addressed in this patch is that
getPrefixedDBkey() is supposed to be a title. It can't contain one of
these placeholders.
Follow-Up: I2c12cc76a9bf01eb527db3ea038e4adc59446cac
Change-Id: Ie994059092df8861ddb97c098acd082698d45c53
Parser::nextLinkID cannot return a string. It returns a positive
integer number.
Note a very similar mistake was already fixed before via I7e71ffc.
Change-Id: Ifce71d0f4db31787bf0eb84e621cfdeb07c674ef
