Hi Ralf,
> Many thanks! I will keep an eye on SVN development and will be available
> for testing!
Philip told me, that I can simply reconstruct repetitions in JIT, instead of
introducing new opcodes and do other changes in the interpreter. The
reconstruction is imprecise, e.g /(?:ab){2}(?:ab)(?:ab)/ is predicted as
/(?:ab){4}/ or /(?:ab)(?:(?:ab)(?:(?:ab)?)?)?/ as /(?:ab){1,3}/, but that is
not a problem in practice. We can even call that as an optimization :)
Here are the compilation statistics of some patterns recently reported as way
too resource hungry:
NOW:
/(a)(?2){0,1999}?(b)/
compile time: 0 ms
compile stack usage: 7008 bytes
/(a)(?(DEFINE)(b))(?2){0,1999}?(?2)/
compile time: 0 ms
compile stack usage: 6088 bytes
/((((((((((\w{4}aa){4}aa){4}aa){3}aa){4}aa){2}aa){4}aa){3}aa){3}aa){11}aa){3}aa/
compile time: 200 ms
compile stack usage: 1912 bytes
WAS:
/(a)(?2){0,1999}?(b)/
compile time: 10 ms
compile stack usage: 889264 bytes
/(a)(?(DEFINE)(b))(?2){0,1999}?(?2)/
compile time: 10 ms
compile stack usage: 889312 bytes
/((((((((((\w{4}aa){4}aa){4}aa){3}aa){4}aa){2}aa){4}aa){3}aa){3}aa){11}aa){3}aa/
compile time: 6300 ms
compile stack usage: 1440775 bytes
However, compiling a pattern with a nested 2000 brackets such as
/((((...(a)))))...)/ can still consume a huge amount of resources, even if it
can be considered as a simple pattern. I have no plans for optimizing them.
Regards,
Zoltan
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
