Google Groups

Re: With regards to the advice given in the new PHP speed tips article Jun 24, 2009 3:20 PM
Posted in group: Make the Web Faster
Hi Gwynne, thank you for your feedback!

A point that I'd like to make, which I hope to include in the article
as well, is that the sites which suffer from slow performance often
aren't those running the latest version of the PHP engine, but rather
older versions such as 4 and even 3.  Many times, and in my own
experience, large amounts of this legacy will exist in a company's
codebase, and updating it to be fully compatible and tested with a
newer version of the PHP engine isn't a viable option.  The purpose of
the tips we're offering in this article is to provide some quick and
easy changes that might help to improve the performance of their code,
without a lot of development overhead.

I do agree that we could do a better job of pointing out the version
differences  in the article, and I'm happy to make those notes and
changes soon.

Additionally, I think that some of our PHP code samples may have been
a bit oversimplified to the point that they are causing some of the
confusion and concerns being discussed here.  I'll be sure to update
those as well.

I hope that your team of developers would be open to contributing to
our selection of articles, so that we all can work together to make
the web faster!


On Jun 24, 9:54 am, Gwynne Raskind <> wrote:
> I would like to apologize in advance to anyone who finds that this  
> message may have been posted to the group more than once. Google  
> Groups seems to be somewhat reluctant to accepting my posting.
> With regards to the new article posted at <
>  >, all of the advice in it is completely incorrect. We at the PHP  
> team would like to offer some thoughts aimed at debunking these  
> claims, claims which the author has clearly not verified.
> 1) "Don't copy variables for no reason".
> The Zend Engine at the core of PHP 4 and 5 uses a technique known as  
> "copy-on-write" memory management. This means that no matter how many  
> times you assign the value of a variable to another variable, the data  
> is not copied until you change it. The example the author gives  
> results in absolutely no significant use of extra memory, as shown in  
> the following example:
> <?php
> $data = str_repeat("*", 512 * 1024); // synthesize 512K of data
> $memory_used_before = memory_get_usage();
> $more_data = $data;
> $memory_used_after = memory_get_usage();
> print "Before: {$memory_used_before}\nAfter: {$memory_used_after}\n";
> ?>
> PHP 5.3 with thread-safety and debugging compiled in:
> Before: 853968
> After: 854236
> PHP 5.2 without thread-safety or debugging:
> Before: 581912
> After: 581976
> A difference of 268 bytes in debugging mode, or 64 bytes in normal  
> mode (which most people use). Hardly the MB of memory the article  
> talks about.
> It should also be noted that a PHP script should NEVER echo or store  
> the raw contents of any user-supplied variable without filtering it  
> appropriately.
> 2) "Use single-quotes for strings."
> Benchmarks run against PHP 5.2 and 5.3 show that parsing double-quoted  
> strings with interpolation is no slower (and often faster) than single-
> quoted strings using concatenation. When simple strings with no  
> variables in them are used, the performance is clearly better with  
> double-quoted strings due to implementation details in the engine. See  
> the benchmark posted at <>.
> 3) "Use echo to print."
> Depending on the way PHP is set up on your host, echo can be slower  
> than print in some cases. Given the example shown, they have equal  
> performance.
> 4) "Don't use concatenation with echo."
> This is exactly the opposite of correct advice. The engine handles  
> multiple arguments to echo() in such a way that concatenation (or  
> double-quoted string interpolation) is actually much faster. See the  
> benchmark posted at <>.
> 5) "Use switch/case instead of if/else."
> Finally, this piece of advice is total nonsense. The decision about  
> when to use switch/case or if/else is purely a matter of coding style;  
> their speeds are generally more or less equal except in certain  
> special cases.
> Most of these points may have been true in ancient versions (PHP 3, or  
> very early versions of PHP 4), but they are definitely untrue in  
> modern PHP. The PHP team urges the author of the article to check his  
> facts more carefully, and to investigate where his claims of extra  
> speed are truly coming from (as certain coding patterns, combined with  
> specific PHP settings, can sometimes make some of the above points  
> partially true).
> We also urge the author to consider the troubling security  
> implications of his examples, at least one of which suggests an  
> extremely dangerous coding style.
> In the words of Alexander Songe, if you're really concerned about the  
> speed of your PHP scripts, look into APC (Alternative PHP Cache, <
>  >) , "which benchmarks show increases speed 3-5 times over no opcode  
> optimization".
> Please feel free to e-mail me at <> (since Google Groups  
> seems to only want to allow me to use my Gmail address to be in the  
> group) with questions. You can also join the php-internals mailing  
> list at <>, or speak to us on the  
> EFNet IRC channel #php.pecl.