Paul M Foster wrote:
On Thu, Jan 28, 2010 at 11:41:43AM -0000, Ford, Mike wrote:
-----Original Message-----
From: Rene Veerman [mailto:rene7...@gmail.com]
Sent: 27 January 2010 22:46
And if your script needs to pass large (> 5Mb) arrays around to
functions, be sure to use passing-by-reference; failing to do so can
double your memory requirements,
possibly hitting the ini_set('memory_lmit', ??)
Have you benchmarked this? PHP's copy-on-change philosophy means there
shouldn't be much difference in memory terms -- so unless you actually expect
to change the array's contents, you should pass by value.
As proof, I constructed this little test:
<snip>
All in all, there is no evidence that passing arrays to functions by value is
inherently more expensive than by reference, and in fact in some cases it can
be significantly cheaper. Which in turn says that you should only pass
arguments by reference when you actually expect to change them, which is after
all what the by-reference operator is there for in the first place! QED.
Counter-intuitive benchmarks. Can we not? Benchmarking something on a
given version of PHP is nice, but changes to the PHP engine occur on a
relatively routine basis. Shall we benchmark each "tip" each time we
change PHP versions, and then rework all our code to conform to the
latest benchmark, depending on the version of PHP our code is running
under?
I've been working with PHP for about 9 years now... I believe
Copy-On-Write was implemented at the outset of PHP 4. This isn't a
feature that tends to change from one version to the next. This feature
has a very very specific purpose and it's a purpose that won't be
discarded anytime soon... if ever.
A better example might be the use of single, versus double quotes.
Regardless of benchmarks, it's logically obvious that if the PHP engine
doesn't have to evaluate the contents inside single quotes, an
expression's evaluation should take less time and use fewer system
resources. Naturally, the PHP engine could be tweaked to equalize
evaluation between single- and double-quote expressions. But this could
also change as the PHP engine is changed.
Single versus double isn't much of an argument... inefficient opcode
generation in the past made one more lucrative than the other, but this
has been pretty much eliminated in the 5 series. As a result of better
opcode generation, the hit to parsing double versus single quotes should
only be happening at the parse stage, not at the run stage.
To put it more simply, we can say that, depending on the version of PHP,
single-quoted versus double-quoted expressions will be evaluated in
equal amounts of time and using equivalent system resources. And if you
prefer to double-quote everything, by all means do so. But the fact
remains that the documentation for PHP says that the contents of a
string delimited by single quotes will not be evaluated, whereas those
within double quotes will be.
This is true to a point... but if we have the following:
echo "blah $foo bleh";
And this produces opcodes:
SET tvar "blah "
CAT tvar $foo
CAT tvar " bleh"
ECHO tvar
And then we have:
echo 'blah'.$foo.' bleh';
And this produces opcodes:
SET tvar "blah "
CAT tvar $foo
CAT tvar " bleh"
ECHO tvar
Then beyond the parse stage these are obviously identical. Thus, in my
own code these days, I use whichever one makes the content easier to
read. For embedding vars into regular content I use double quotes, for
outputing HTML I tend to use single quotes so that I don' t need to
escape the double quotes for the tag attributes.
What these tips are about is coding things using best practices, derived
from logical examination of the way PHP is advertised to function, not
transitory benchmarks.
It helps to have a keen insight into not just how to use PHP, but how
PHP itself works. This is where studying history, the PHP code itself,
parsers, compilers, optimizers, virtual engines, etc will aid in your
understanding of the underlying architecture. Of course, many of these
pursuits lie more in the field of Computer Science than in the realm
code monkeying :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
