The change below removes the success part of the super-linear cache code
in the regex engine. None of the tests in the test suite ever triggered
it, and I'm unable to think of an example that could. If I'm wrong,
some of you may find one or more of your regexes suddenly taking
universe-heat-death time to execute. if so, let me know!
I've talked this over with Hugo, and I've half-convinced him that this is
correct :-)

Fri, Jul 14, 2006 at 01:32:10PM +0100, hv (AT) crypt (DOT) org wrote:
Dave Mitchell <davem (AT) iabyn (DOT) comwrote:
:The change below removes the success part of the super-linear cache code
:in the regex engine. None of the tests in the test suite ever triggered
:it, and I'm unable to think of an example that could. If I'm wrong,
:some of you may find one or more of your regexes suddenly taking
:universe-heat-death time to execute. if so, let me know!
:
:I've talked this over with Hugo, and I've half-convinced him that this is
:correct :-)

At least 90% convinced.

Do you plan to expose also the iteration counter we talked about? That
would make it possible to introduce some optimisation tests, at least
under a debugging build.

Er, I wasn't planning to. What I did was a quick'n'dirty hack that
certianly isn't yet suitable for public consumption. It seems a bit odd
having a a special debug facility that just prints out the number of times
the WHILEM: branch is taken. Perhaps a more general instrumentation
facility could be added, although I'm not sure what that might look like.