I have to admit to getting lost trying to read that article. However, ignorance is no reason to fail to comment ;-) In all honesty, I pretty much stopped reading after the first pair of graphs and it appearing that they were picking some rather pathological cases. They were picking on Perl's well-known worst-case scenarios, and comparing them to another regex engine that had chosen differing optimisations. I'm sure that someone here could pick another pathological expression that would highlight perl's vast superiority in optimisation on that string - which, most likely, would completely avoid the regular expression engine. Neither one would be a fair comparison.

The idea really is to pick realistic data for your use (which could be delimited text, log files, shell scripts, perl code, etc., or, heaven forbid, actual regular text), and compare with that.

Where grep and awk really fall down is that to do anything remotely interesting as far as complex programming is concerned, you need to encapsulate them in a shell script. At that point, you have the overhead of forking and execing hundreds or thousands of subprocesses (including awk and/or grep), which probably vastly overshadows any possible perl slowdown on regular (non-pathological) data.