Re: [pcre-dev] Strangely long matching times. Could anyone h…

Góra strony
Delete this message
Autor: Zoltán Herczeg
Data:  
Dla: pcre-dev@exim.org, Ralf Junker
Temat: Re: [pcre-dev] Strangely long matching times. Could anyone help to explain?
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