Hi,
is this measured with JIT enabled? I wrote an introduction about the JIT compiler before:
https://zherczeg.github.io/sljit/pcre2_jit.html
The single character optimization described in the paragraph containing the (*SKIP) verb should handle it.
Regards,
Zoltan
-------- Eredeti levél --------
Feladó: Ralf Junker < ralfjunker@??? (Link ->
mailto:ralfjunker@gmx.de) >
Dátum: 2020 november 28 10:49:37
Tárgy: Re: [pcre-dev] Strangely long matching times. Could anyone help to explain?
Címzett: pcre-dev@??? < pcre-dev@??? (Link ->
mailto:pcre-dev@exim.org) >
Thank you, Philip, for the explanation. no_start_optimize certainly
makes sense.
What I still do not understand is why atomic grouping does not speed up
the search? Theses two patterns are equally fast/slow:
# Failure with extra letter "a" is very slow (> 6000 ms).
/aa.*?bba/
\[aa bb ]{200}
# Atomic grouping does not help (each > 6000 ms).
/aa(?>.*?bba)/
\[aa bb ]{200}
Shouldn't the atomic group prevent backtracking and run much faster?
Ralf
On 20.11.2020 17:05, Philip Hazel wrote:
> The explanation is that the fast ones benefit from a start-up
> optimization. For example, with the added x it knows there must be an
> x in the subject and it does a preliminary check. Same for y. Not the
> same for an added a. If you run with no_start_optimize the fast ones
> will be slow and the slowness in all cases is because it is checking
> a rather large search tree.
--
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev
