https://bugs.exim.org/show_bug.cgi?id=2430
--- Comment #1 from Philip Hazel <p...@hermes.cam.ac.uk> --- You missed the leading [ in "aA][bB][cC]" but I assume that's just a typo in your posting, as it is present in your example. Investigating your patterns shows that this is an effect caused by an optimization that happens in one case, but not the other. Actually, it's an optimization that turns into a pessimization. For (?i)abc PCRE2 records that a match must start with "a" and there must be a "c" later in the source. For [aA][bB][cC] it records only that a match must start with "A" or "a". It seems that searching for "c" (which may be a long way after each "a") is taking up lots of time. (Note, however, that if you use JIT, the problem doesn't occur.) I will take a look at this - it occurs to me that searching for a "last fixed character" is a bit pointless unless there is something variable between it and the first character. Also, the search should perhaps only search so far after the initial character. If you turn off the optimizations with NO_START_OPTIMIZE the two patterns behave much the same. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
