2008. 03. 28, péntek keltezéssel 10.59-kor Robert Cummings ezt írta:
> On Fri, 2008-03-28 at 15:30 +0100, Zoltán Németh wrote:
> > 2008. 03. 28, péntek keltezéssel 10.24-kor Robert Cummings ezt írta:
> > > On Fri, 2008-03-28 at 14:46 +0100, Zoltán Németh wrote:
> > > >
> > > > yeah maybe. you're right, the bytecode is the same. but somewhere I
> > > > heard that the parsing is the same too - because escaped characters can
> > > > be in any string, though I'm not that sure about this anymore, as my
> > > > link proved something else ;)
> > >
> > > Single quoted strings do support some escape characters. As far as I
> > > know only you can only escape a single quote and a backslash when
> > > creating a string via single quotes.
> >
> > yes, but I think the parser would still need to tokenize the string and
> > verify each token whether it contains an escape character or not - which
> > should be the same process as tokenizing and checking for escape
> > character and $ signs.
>
> Nope, when processing a single quoted string there should be 4 available
> parse branches:
>
> EOF
> ' (end of string)
> \
> EOF
> \
> '
> anything else
> anything else
>
> Whereas with a double quoted string you have something along the lines
> of:
>
> EOF
> " (end of string)
> $ (begin variable)
> { (possible begin interpolation)
> $ (begin interpolation)
> \
> EOF
> \
> '
> "
> t
> n
> r
> x
> v
> f
> <digit>
> anything else
> anything else
>
> So presuming no variable is embeded and assuming no escaped
> characters... double quotes still need to check for the beginning of
> variable interpolation which has 2 different start possibilities. With
> respect to creating the byte code single quotes have 4 branches, double
> quotes have 6 branches in the simplest of cases with no escape and no
> interpolation. So one would expect compile time for double quotes to be
> approximately 33% slower than for single quotes.
good points, thanks for the detailed info (not that I'd focus on it
while coding but its sooo interesting :) )
> Once compiled though,
> the point is moot especially since most sites use a bytecode cache like
> eAccelerator or APC. Even without a cache htough, the time difference is
> teeeeeeeency, and this is just for informational purposes :) There are
> usually bigger eggs to fry when optimizing.
sure, these questions like 'echo or print' and 'single or double quotes'
and 'for or while' and so on should never be mentioned when talking
about real life code optimizing, as the difference they may make is so
minimal. talking about these is good only for satisfying some of my (and
maybe some other people's) curiosity about how php works internally :)
> One last thing though...
> even if this were escaped and even if there were fifty variables
> embedded, a good bytecode optimizer (not quite the same as a bytecode
> cacher) would optimize the bytecode for caching so that the string is
> broken up according to what needs to be interpolated and what does not.
could you tell me more about this bytecode optimizer stuff? how does it
work, how much better/faster is it then APC/EAccelerator/etc?
greets,
Zoltán Németh
>
> Cheers,
> Rob.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
