On Mon, 26 Jan 2015, Zoltán Herczeg wrote:
Tracking the subpattern index would require dynamic memory
allocation, which is not preferred in PCRE, since memory allocation is
slow.
Yes, that is exactly it. When I first designed PCRE, back in 1997, I
wanted to avoid memory allocation at
The (?:abc){1234} is a simple case, but sometimes you need to track the status
of the subpattern. E.g. when you match /(?:aa|a){6}/ to aa (this is a badly
written, but possible pattern requires exponential matching time). The engine
greedily matches aa at the beginning, but eventually it
Zoltan,
At 07:17 26/01/2015, you wrote:
the pattern is always compiled to byte code first, and JIT converts
it back, so using JIT alone does not help.
Ah, I didn't knew that point.
The reason of not using an iterator in the interpreter is
practical: PCRE
At 18:30 25/01/2015, you wrote:
´¯¯¯
I think the issue is that the byte code of the pattern is too big.
It is basically (?:\d+=) times. It was easier to implement the
interpreter this way (JIT converts back the byte code into an
interator again, because of the code
Hi,
the pattern is always compiled to byte code first, and JIT converts it back, so
using JIT alone does not help. The reason of not using an iterator in the
interpreter is practical: PCRE interpreter uses stack recursion, and you cannot
easily share variable data across function calls. This
