optimilize web page loading

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. 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. 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.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

At 9:14 AM +0100 3/28/08, Zoltán Németh wrote:
> > This way for literal strings, the PHP parser doesn't have to evaluate
> > this string to determine if anything needs to be translated (e.g.,
> > $report .= "I like to $foo"). A minimal speedup, but nonetheless...
>
>that above statement is simply not true. parsing "foo" and 'foo' is all
>the same
>a good read about it:
>http://blog.libssh2.org/index.php?/a...of-string.html
>
>greets,
>Zoltán Németh

I read it, but it still doesn't disprove the premise.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

At 10:59 AM -0400 3/28/08, Robert Cummings wrote:
>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. 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. 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.

As always, thanks for your most excellent explanation. I figured that
something along those lines was happening. I didn't consider the
escape concerns.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

My method was.

Store into global thingy. Then echo very end of the page.

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.

2008. 03. 28, péntek keltezéssel 11.31-kor tedd ezt Ã*rta:
> At 9:14 AM +0100 3/28/08, Zoltán Németh wrote:
> > > This way for literal strings, the PHP parser doesn't have to evaluate
> > > this string to determine if anything needs to be translated (e.g.,
> > > $report .= "I like to $foo"). A minimal speedup, but nonetheless...
> >
> >that above statement is simply not true. parsing "foo" and 'foo' is all
> >the same
> >a good read about it:
> >http://blog.libssh2.org/index.php?/a...of-string.html
> >
> >greets,
> >Zoltán Németh
>
> I read it, but it still doesn't disprove the premise.

yeah, that was morning time and I got mixed up a bit :)

Anyway, I had to admit that I was wrong in this matter, Rob Cummings has
just proven me that there is a difference, however little is it

greets,
Zoltán Németh

>
> Cheers,
>
> tedd
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>

On Sat, 2008-03-29 at 10:16 +0100, Zoltán Németh wrote:
> >
> > 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?

It really depends on what an optimizer optimizes. TurckMMCache had.has
an optimizer. Zend offers an optimizer too. Optimizer can work in a
number of ways. They may be an explicit part of the bytecode cache
mechanism or possibly plugged as one element in a chain of bytecode
processors... parser -> optmizer -> cacher. I'm not exactly sure how it
works for PHP.

The main difference between a cacher and an optimizer though is that
generally speaking a caher only deals with caching the bytecode. No
processing occurs on the produced bytecode. On the other hand an
optimizer may perform alterates on the bytecodes to enhance speed.

For example... by now most people on the list probably know that:

++$i;

Is faster than:

$i++;

An optmizer might see $i++ and determine that the return value is not
used and thus the operation can be changed from $i++ to ++$i. Smilarly,
the optimizer might encounter the following expression:

$foo = 1 << 8

And reduce the constant expression (1 << 8) to (256). So the expression
essentially becomes:

$foo = 256

Similarly if you take the following expression:

$text = "There was an old man from Nantuckit\n"
."Who's sole possession was a bucket.\n"
."One day with a grin,\n"
."While scratching his chin\n"
."He thought, \"I think I'll build a rocket.\"\n";

This could be optimized by removing concatenation operations and
producing a single unified string within the bytecode.

These are just basic optimizations obviously. Optimization is not a new
thing, if you've ever used the -O flags when building a C program then
you know that C compilers can also perform optimizations.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

Robert Cummings Ã*rta:
> On Sat, 2008-03-29 at 10:16 +0100, Zoltán Németh wrote:
>>> 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?
>
> It really depends on what an optimizer optimizes. TurckMMCache had.has
> an optimizer. Zend offers an optimizer too. Optimizer can work in a
> number of ways. They may be an explicit part of the bytecode cache
> mechanism or possibly plugged as one element in a chain of bytecode
> processors... parser -> optmizer -> cacher. I'm not exactly sure how it
> works for PHP.
>
> The main difference between a cacher and an optimizer though is that
> generally speaking a caher only deals with caching the bytecode. No
> processing occurs on the produced bytecode. On the other hand an
> optimizer may perform alterates on the bytecodes to enhance speed.
>
> For example... by now most people on the list probably know that:
>
> ++$i;
>
> Is faster than:
>
> $i++;
>
> An optmizer might see $i++ and determine that the return value is not
> used and thus the operation can be changed from $i++ to ++$i. Smilarly,
> the optimizer might encounter the following expression:
>
> $foo = 1 << 8
>
> And reduce the constant expression (1 << 8) to (256). So the expression
> essentially becomes:
>
> $foo = 256
>
> Similarly if you take the following expression:
>
> $text = "There was an old man from Nantuckit\n"
> ."Who's sole possession was a bucket.\n"
> ."One day with a grin,\n"
> ."While scratching his chin\n"
> ."He thought, \"I think I'll build a rocket.\"\n";
>
> This could be optimized by removing concatenation operations and
> producing a single unified string within the bytecode.
>
> These are just basic optimizations obviously. Optimization is not a new
> thing, if you've ever used the -O flags when building a C program then
> you know that C compilers can also perform optimizations.
>
> Cheers,
> Rob.

thanks, I get the concept

greets,
Zoltán Németh

The biggest speedup in page loading is still enabling gzip

<?php
ob_start("ob_gzhandler");
// output
ob_flush();
?>


--
If at first you dont succeed
try try try again
If at first you do succeed
try not to look surprised

_
"Zoltán Németh" <znemeth@alterationx.hu> wrote in message
news:1206782619.7711.1.camel@localhost...
> 2008. 03. 28, péntek keltezéssel 11.31-kor tedd ezt írta:
> > At 9:14 AM +0100 3/28/08, Zoltán Németh wrote:
> > > > This way for literal strings, the PHP parser doesn't have to
evaluate
> > > > this string to determine if anything needs to be translated (e.g.,
> > > > $report .= "I like to $foo"). A minimal speedup, but nonetheless...
> > >
> > >that above statement is simply not true. parsing "foo" and 'foo' is all
> > >the same
> > >a good read about it:
> >
>http://blog.libssh2.org/index.php?/a...piece-of-strin
g.html
> > >
> > >greets,
> > >Zoltán Németh
> >
> > I read it, but it still doesn't disprove the premise.
>
> yeah, that was morning time and I got mixed up a bit :)
>
> Anyway, I had to admit that I was wrong in this matter, Rob Cummings has
> just proven me that there is a difference, however little is it
>
> greets,
> Zoltán Németh
>
> >
> > Cheers,
> >
> > tedd
> > --
> > -------
> > http://sperling.com http://ancientstones.com http://earthstones.com
> >
>