Re: [PATCH] Major optimization for heredocs/interpolated strings

Hi Marcus, Yeah, I did a lot of benchmarking different things ;-) and mentioned some statistics in my original message -- such as 10-15% *overall* improvement using ApacheBench on a few scripts. The difference for specific strings depends on what the string looks like (length, etc.), but is always faster for both scan/compile time and runtime. The difference is huge with, for example, a longer heredoc without variables, like the one in Sara's blog entry. And as I also mentioned, removing the ^ beginning-of-line operator from the old heredoc end token rule, it makes YY_RULE_SETUP empty in the generated C file, which had been setting yy_at_bol for *every* token matched, just for the one rule that used it. Eliminating that overhead for each token made a measurable difference in *overall scanner performance* -- I'm sure there's less difference with non-ZTS builds since YY_RULE_SETUP was referencing globals. BTW, regarding HEAD, for you, Andrei, or anyone, I think I noticed a bug, unrelated to my changes: CG(literal_type) isn't set for backticks in the parser, so it winds up being whatever was last set. I would've changed it, but didn't know if it's supposed to always be IS_STRING or dependent on UG(unicode). Thanks, Matt ----- Original Message ----- From: "Marcus Boerger" Sent: Thursday, April 26, 2007 > Hello Matt, > > the patch looks interesting. I think we should commit it to HEAD. And > if it works good we can add it to 5.3 once we created it. Did you do any > measurements? > > best regards > marcus > > Thursday, April 26, 2007, 5:52:43 AM, you wrote: > > > Hi again, > > > Hmm, not a single reply about this patch...? Did anyone try it out? :-) > > Think it can be used after 5.2.2? > > > > Matt