[PATCH] Major optimization for heredocs/interpolated strings

> 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

> ----- Original Message ----- > From: "Matt Wilmas" > Sent: Thursday, April 12, 2007 > Subject: [PHP-DEV] [PATCH] Major optimization for heredocs/interpolated > strings

>> Hi all, >> >> I think I first realized that PHP's scanner splits non-constant strings > into >> many "pieces" after reading Sara's "How long is a piece of string?" blog >> entry[1] last summer. At the time I didn't know much about the internals >> and didn't know if anything could be done to change it. Then in the fall > I >> finally took a look at the scanner ;-) and thought it would be possible to >> only "split" strings at variables. Finally a few months ago, I began >> working out the changes -- it was working almost 2 months ago, but then I >> got sidetracked :-/ from doing some more testing and making a few semantic >> token changes till now. >> >> So anyway, now heredocs and interpolated strings should be pretty much > just >> like constant strings and concatenation (except for the extra INIT_STRING >> opcode). They scan/parse/compile faster (with less memory), run faster, > and >> there's less to free when destroying opcodes. >> >> With a simple string like "This is $var string" (say $var = 'some'), I > found >> the compile/cleanup time to be up to 50% faster, and runtime 55% faster! >> (Note: To test compile time, I eval()'d about 50 of them in an if (0) > {...} >> block.) The difference will be *much more* depending on how many "pieces" >> there would've been before (e.g. longer). >> >> The more complex rules increased the size of Flex's tables about 40%. >> However, removing the old heredoc end rule, which used the ^ >> beginning-of-line operator, made the YY_RULE_SETUP macro be empty, saving >> some space. The net result was an 8K/12K larger binary in 5.2/HEAD. I > was >> surprised at the overall performance increase without the ^ rule. Its >> saving a few operations per match made just about as much difference as >> Flex's -Cfe table compression (was playing with that first :^)) when >> compiling the code from Zend/bench.php (5% I think). >> >> This was with a Windows ZTS build. Running ApacheBench on a few different >> scripts showed pretty nice overall improvements -- 10-15% was common in my >> quick tests. >> >> BTW, removing that ^ rule lifts the requirement that the character before >> the closing heredoc label "must be a newline as defined by your operating >> system," to quote the manual. >> >> Now some of the other changes: >> >> The ST_SINGLE_QUOTE state was removed from 5.2, like in HEAD. >> >> A string like "$$$" is considered constant now, since that's really what > it >> is, right? >> >> CG(zend_lineno) wasn't incremented before if a \n or \r newline (not \r\n) >> followed a backslash in a non-constant string. \{ returned T_STRING > instead >> of T_BAD_CHARACTER like any other invalid escape sequence. (Note: Of > course >> these won't usually match now anyway, but will be part of a longer > string.) >> >> I removed HANDLE_NEWLINES() from the code that scans a string's text, >> instead doing the newline check in the escape-checking loop, to prevent >> scanning twice. And I removed the additional boundary check in >> HANDLE_NEWLINES() and elsewhere since I didn't see the need -- AFAIK in > all >> cases you'll only hit '\0'. >> >> I removed the one <<EOF>> rule since it was missing some states and it >> wasn't doing anything that the default EOF rule doesn't by calling >> yyterminate(). >> >> In zendlex(), the goto target doesn't need to recheck CG(increment_lineno) >> since it hasn't changed, and I simplified the closing tag newline check >> (also looked like it would miss \r ones). >> >> Sorry for the long message! I'll send another if I think of something I >> forgot to mention. Here are the patches: >> >> http://realplain.com/php/scanner_optimizations.diff >> http://realplain.com/php/scanner_optimizations_5_2.diff >> >> Appreciate any feedback, or questions about any of it. :-) >> >> >> Thanks, >> Matt >> >> [1] >> > http://blog.libssh2.org/index.php?/archives/28-How-long-is-a-piece-of-string.html

> The updated 5.2 patch is at the same address, > http://realplain.com/php/scanner_optimizations_5_2.diff, and the original > was moved to http://realplain.com/php/scanner_optimizations_5_2-v1.diff

> The updated 5.2 patch is at the same address, > http://realplain.com/php/scanner_optimizations_5_2.diff, and the original > was moved to http://realplain.com/php/scanner_optimizations_5_2-v1.diff >