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.
