develooper Front page | perl.perl5.porters | Postings from April 2011

[perl #76546] regex engine slowdown bug

Thread Previous | Thread Next
Alex Efros via RT
April 1, 2011 01:24
[perl #76546] regex engine slowdown bug
Message ID:
Чтв. Мар. 31 01:16:36 2011, demerphq писал:
> We never fixed the superlinear cache bug that was broken some time
> around when the engine was derecursivized.
> Id bet a dollar this is related.

BTW, your YAPH signature remind me about -Mre=debug, and I tried to 
compare these regexps this way. Results are interesting, but, sadly, I 
don't know perl internals good enough to understand them:

$ perl -Mre=debug -e "/<X[^>]*>(.*?)(?=<a)/gis"
$ perl -Mre=debug -e "/<X[^>]*(?i-:>)(.*?)(?=<a)/gis"
produce same output and work fast, but this one differs and slow:
$ perl -Mre=debug -e "/<X[^>]*(?-i:>)(.*?)(?=<a)/gis"

Last line in first two (fast) regex was:
  stclass EXACTF <<X> minlen 3
but in last (slow) regex it was:
  floating ">" at 2..2147483647 (checking floating) stclass EXACTF <<X> 
minlen 3

Right now we've huge amount of parsers working 24x7 with thousands of 
different regexps, and it's SLOW. Can anyone give some recommendations 
about how to work around this issue - like "add /i flag to every regex 
whenever possible", etc.? Because for now I'm even doesn't sure adding 
this redundant /i doesn't slowdown one regexp while speeding up another…

WBR, Alex.

P.S. I hope one lucky day we'll find libre2 support in perl, using some 
pragma to switch between current perl regexp engine and libre2 - they 
are mostly compatible, but libre2 guarantee constant execution time and 
I'm really tired of regexps which at some moment decide to spend few 
minutes for execution instead of nanoseconds.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About