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 < ralfjun...@gmx.de (Link -> mailto:ralfjun...@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@exim.org < pcre-dev@exim.org (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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev