Re^4: Perl regexp matching is slow??

In my humble experiaence as a has-been article writer, editors often stretch the wording of article titles to increase the apparent controversy. :(

I totally agree with you that the author was less than balanced in his coverage, but, again, I must admit that I've fallen prey to the same lack of diligence.

Thanks for your clarity in posting these numerous insights and details of matching for us, demerphq. I don't claim to be an expert, but your analysis will help me understand the science of matching a little better. :D

Don Wilde
"There's more than one level to any answer."

Comment on Re^4: Perl regexp matching is slow??

Replies are listed 'Best First'.
Re^5: Perl regexp matching is slow?? by demerphq (Chancellor) on Feb 01, 2007 at 08:24 UTC
but your analysis will help me understand the science of matching a little better No, my analysis wont help with that, for the science of matching read the original paper. My analysis is that of the merits of using a backtracking NFA as the basis for a general purpose matching engine for use in something like perl. My beef with the paper is purely with the criticism of Perl (and other platforms) for using a backtracking engine. I dont think its a bad decision, I think its just a decision that is motivated by considerations beyond just match time performance, and I felt that the article, given its title, should have in the name of balance or fairness or whatever at the very least discussed them. However these arent scientific issues, they are engineering issues. For scienctific stuff read the academic literature. For engineering stuff read the source of as many implementations as you can get your hands on. :-) --- $world=~s/war/peace/g	[reply]
Re^6: Perl regexp matching is slow?? by samizdat (Vicar) on Feb 02, 2007 at 11:56 UTC
A lot of the challenge in programming is in choosing the right tools, as you know. It is true that to understand the underlying guts, studying academic (?) papers and source code is the right way to proceed. I should have said "help me understand how to use the science of matching". I'm building a C extension library that embeds LISP concepts (and more) in C, and, yes, Allen's "Anatomy of LISP" helps me optimize it, but Patrick Henry Winston's "LISP" showed me what features I needed to have and gave me the insights I needed to extend it in useful ways. It's often difficult to see past an author's bias in a technical paper. Having experts such as yourself comment and complement the original discourse adds immeasurably to the utility of the work, and that's what I was praising you for. Don Wilde "There's more than one level to any answer."	[reply]