A Note on Google’s So-called Best Practices

Tweet

Earlier this week, Google launched a campaign to make the web faster. It appears to be a call for improving the quality of web sites in general, but with a focus on performance.

The project includes an article on “PHP performance tips”, which is bordering on being ridiculous. There are of course lots of blog posts with similar nonsense around the web, but since this is being endorsed by Google, it’s fair to assume that people might take it at face value. That’s unfortunate, as almost none of it is true. The PHP Team responded back with this message, wherein they refute the unfounded nonsense.

What’s more troubling however, is the whole approach to performance optimisation as a matter of “knowing the secret handshake”. Optimisation is far more complex than that, and spending time on these “optimisation tricks” are rarely worthwhile and might often lead to unmaintainable code, if applied too early. It’s a fine line, because there are of course certain things that you shouldn’t do (such as hit the database within a tight loop, if you can send one query instead), but there are likewise lots of things that are a complete and utter waste of every body’s time. It’s a pity that this article failed to keep those two issues separate. download movies

Performance optimisation is not magic. The real way to deal with it, is to measure and analyse. It is almost impossible — even for a highly skilled programmer — to anticipate exactly where there might be bottlenecks in a program. Using a profiler gives you real numbers to relate to, rather than wild guesses and superstition.

For PHP scripts, there is the freely available Xdebug extension, which provides detailed information on both memory usage and execution time on a per-function basis. It’s easy to install and with the simple WebGrind as a front-end, you’ll be up and running in no time.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.dangrossman.info Dan Grossman

    Wow, first time I took a look at that article, and as you said, it’s ridiculous. A single round trip to a database is going to take longer than all the time you’d save avoiding string concatenation and other nonsense they’re suggesting.

  • atsa

    Great Post….

    Thanks for sharing

  • NuWeb.co.uk

    // I can not belive that google
    echo “that $expletive crap”;

  • PCSpectra

    About the only practice I employ that I disagree with is: Don’t copy variables for no reason.

    That was kind of silly…most developers favour the truly local variables for readability as super globals look nasty for the most part.

    Most other practices are common sense. Executing multiple queries in a loop…It might make sense to concatenate the queries into a single string and then execute, but isn’t that what prepared statements are for? If performance is that big of an issue, just make sure your target environment has a DB with mysqli or PDO or something.

  • Shadow Caster

    So what is the best thing to do to improve performance?

  • Jason Stubbs

    While it’s true that most of the optimizations listed are micro and the reasons given are not true, the refutes are going too far as well.

    Don’t copy variables for no reason
    The memory usage argument is wrong, but there is extra time taken creating an extra local variable.

    Use single-quotes for long strings
    The refute talks about a double-quoted string versus concatenation of several single-quoted strings. Google’s point talkes about single-quoted strings in both cases. However, this point is moot if using an op-code cache (doesn’t everybody?) as an invariant double quoted string results in the same representation as a single-quoted string.

    Use switch/case instead of if/else
    This does lead to more performance as there is only one namespace lookup made in the case of a switch statement.

    Yes, these are micro-optimizations and are unnecessary except in the tightest of loops, but they aren’t really such bad habits to get into…

  • http://www.primalskill.com feketegy

    There are some points that actually speeds things up and still preserve a maintainable code. For example the single and double quotes section.

    But the rest seems crap… like the switch and if/else section or the most ridiculous is the don’t copy variables section…

  • leelong

    but i prefer readability and maintainability to these micro-optimizations.

  • Troels Knak-Nielsen

    The refute talks about a double-quoted string versus concatenation of several single-quoted strings. Google’s point talkes about single-quoted strings in both cases. However, this point is moot if using an op-code cache (doesn’t everybody?) as an invariant double quoted string results in the same representation as a single-quoted string.

    I’d say it’s moot in any case. Unless you have a very atypical application, the performance that can be gained by replacing double quotes with single quotes is a drop in the ocean (And have you seen the ocean? It’s really big, I tell you). Even if it doesn’t make your code less readable, it’s still time you’ve spent on nothing.

    Recently, I’ve been trying to use the different quoting styles to denote the intention of a string. If it’s a string constant (Such as a named index in an array), I’ll use single quotes, if it’s literal text, I’ll use double quotes.

    It might make sense to concatenate the queries into a single string and then execute, but isn’t that what prepared statements are for? If performance is that big of an issue, just make sure your target environment has a DB with mysqli or PDO or something.

    MySql generally doesn’t allow you to execute multiple queries in one call and that’s probably a good thing (From a security perspective). However, multiple select queries can often be rewritten to a join.

    Prepared statements doesn’t save you from making additional calls to the database, but they do save the database server from re-parsing the query, and they also make the actual data transfer slightly smaller. Since a database is usually on a different machine, this means that even with prepared queries, a database call is still a very expensive operation and as such, you should generally try to minimise them.

  • Ren

    Read the article few days ago, and alot seemed bunk.

    Thought the string concantenation vs comma with echo depended on output buffering. But again pretty moot point, prefer using commas just for the better syntax highlighting.

  • Jasc

    Or better yet, don’t use a crappy language that forces you to write awful code in the name of performance.

    Radical idea, I know.

  • Wardrop

    The poor author of that article has been slammed so unreasonably by blogs like sitepoints. In fact, I find most of the bloggers look more stupid than the author of the article. It seems that the biggest ‘controversy’ is around the following points, which I’ll clarify on behalf of the author of that article (someone has to)…

    Don’t copy variables for no reason.
    This is a good point that he makes, and it is absolutely, 100% true. The author here is NOT talking about simply assigning one variable to another (ie. $var1 = $var2), as obviously PHP just maps the same value to each, however, if $var2 was changed (as in the authors example, if anyone actually looked at it), then it will use double the memory as you’re now storing the original variable value in $var1, and a modified version in $var2. $var1 isn’t needed any more, so it just sits around taking up space. If you feel you must assign one variable to another, simply for aesthetic reasons, then it wouldn’t be a bad idea to unset the original variable if you don’t plan on using it again. Of course, this only applies when there’s a chance the variable could be quite large, in the case of user submitted data or a database record, etcetera.

    Use switch/case instead of if/else.
    He makes a perfectly valid point here, however he should have mentioned in what context this applies, although keep in mind, he doesn’t want to confuse the beginners which this article is targeted at. Anyway, let me give an example of where a switch/case statement can offer a performance improvement over an if/else statement…

    if(calculate($var1) == ‘horse’)
    {
    // Do this
    }
    else if(calculate($var1) == ‘donkey’)
    {
    // Do this
    }
    else if(calculate($var1) == ‘zebra’)
    {
    // Do this
    }
    else
    {
    // Do this
    }

    switch(calculate($var1))
    {
    case ‘horse':
    // Do this
    case ‘donkey':
    // Do this
    case ‘zebra':
    // Do this
    default:
    // Do this
    }

    As you can see, the switch statement would obviously be the faster method as it only has to run the calculate() function once. Depending on the time it takes for the calculate() function to run, and the number of cases required, this could speed up a php script/app considerably.

    Use single-quotes for long strings.
    If he is wrong in saying this, then it’s understandable when you consider two things.

    1) Simple thinking would suggest that there must be some overhead involved in parsing a double-quoted string looking for variables.
    2) Not too long ago, the manual use to say: “Parsing variables within strings uses more memory than string concatenation”. It was only recently removed which suggests that either PHP has changed how it deals with double-quoted strings (or concatenation), or those who wrote the documentation decided it’s not appropriate for the manual. In either case, the author should be forgiven, not bashed (by blogger thugs – yes, they exist).

    It irritates me to see how much this guy’s being bashed unnecessarily. If you think none of these optimisations are worth the effort, then have you considered that after only a couple of hours using these tips, it would become second nature, and you’d probably find yourself implementing these simple optimisations out of force of habit. I mean, why not do it?

  • http://keryx.se itpastorn

    Why not read the core PHP team debunk Googles article. Simply the best resource for this discussion: Gwynne Raskind’s replyon Google groups.

  • Troels Knak-Nielsen

    The poor author of that article has been slammed so unreasonably by blogs like sitepoints. In fact, I find most of the bloggers look more stupid than the author of the article.
    It irritates me to see how much this guy’s being bashed unnecessarily.

    When someone writes on behalf of Google, he must be prepared to be scrutinised more thoroughly. I have no personal beef with the author (in fact, I don’t even know who he is), and I didn’t try to make this any kind of attack on his person. I don’t see how it could be interpreted as such either. The problem is that this is an educative programme, and people are going to take information from Google as being true. Therefore they must meet higher standards than most everybody else.

    It seems that the biggest ‘controversy’ is around the following points, which I’ll clarify on behalf of the author of that article (someone has to) …

    My biggest problem with this article is not about the individual tips being true or not (Though they are in fact wrong), but rather that focusing on micro-optimisations sends the wrong signal to would-be programmers. The choice between using a switch or an if-statement should not be made on the grounds of performance. That is worst-practise, not best.

  • http://www.dangrossman.info Dan Grossman

    @Jasc: Nobody here is talking about such a language, as that certainly doesn’t describe PHP. Were you referring to Java perhaps?

  • http://www.olsenportfolio.com/ nrg_alpha

    @Wardrop: Granted, your code example of the if/else statement is not a fair comparison, as you are executing calculate($var1) in every condition, which is not wise coding practice. That would be akin to always executing say count() in a for loop;

    for ($a = 0 ; $a < count($var1) ; $a++) {
    // do something;
    }

    The smarter comparison would be to assign calculate($var1) to a variable [i]once[/i], then throw that through your if/else statement:

    $calc = calculate($var1);
    if($calc == ‘horse’)
    {
    // Do this
    }
    else if($calc == ‘donkey’)
    {
    // Do this
    }
    ….

    Of course, in this hypothetical situation we don’t know what the function calculate() does.. but it doesn’t matter. Having the PHP engine do more work than necessary is just plain bad practice.

  • Wardrop

    @nrg_alpha…

    Sure, assigning a variable would speed up the if/else syntax, but it’s unnecessary when the switch/case syntax can achieve the same thing without populating the namespace you’re in. Plus in such a scenario, the switch/case statement is much cleaner.

    @Troels…

    You bash an authors article, and you’re effectively bashing the author. I understand that as Google, you probably would expect a little more from them in terms of the quality of their tips (these tips are very short and to the point, they could have been elaborated), along with their explanations and examples, but I don’t agree with summarising the article as “border-line ridiculous” or “wrong”. All he’s suggesting are best practices, which as a bonus, get you a slight performance improvement. He even mentions toward the beginning of the article…

    Premature optimization is the root of all evil

    As I’ve said, I can’t fault any of the authors tips. If there’s one thing the authors done wrong, it’s not elaborating on each of his points a little more.

  • Hamranhansenhansen

    Writing for Google doesn’t mean a single thing. You can’t trust Google any more than anyone else. Perhaps less, because Google has a fairly unique position on the Web and things that work for them may be opposite to you. Also, Google is about 98% Ph.D’s, which on one hand is great, but on the other hand, Ph.D’s are the most ignorant smart people you will find. Most have not had a real job. Most have the creativity of a turnip.

    It’s better to Google “PHP optimization” than to read an article on PHP optimization by someone who works at Google. If you want to take Google’s advice, stop using Microsoft products. That is PHP’s advice also and mine too.

  • http://art4eye.com -T-

    I usually just follow the tips posted at http://www.phpbench.com/
    They seem to be solid enough


    $precalculatedCount = sizeof($array);
    for($i=0; $i < $precalculatedCount; $i++)
    {...}

    // instead of

    for($i=0;$i < sizeof($array);$i++)
    {...}

  • Arkh

    Let’s be honest. PhP is not C : if you want perfs you don’t choose it. Wasting hours to gain 1ms of execution time, getting a less readable code while your Db connexion are using dozens ms ? Not worth it.
    Start by getting a working and as secure as you can app. Optimize your server config. Optimize your db requests. Then you can think about getting some ms from your php code if you still have time for that.

  • http://www.patricksamphire.com/ PatrickSamphire

    Ph.D’s are the most ignorant smart people you will find. Most have not had a real job. Most have the creativity of a turnip.

    This may be the most absurd comment in the thread so far. If someone is working for google, they have a real job. Anyone working for a salary has a real job. This stupid snobbishness doesn’t help the debate at all.

  • Anonymous

    @wardrop:

    You bash an authors article, and you’re effectively bashing the author.

    Um, no, this is the exact opposite of an ad-hominem. We are supposed to be good at logic. And, according to the author of this post, the individual points mentioned in the post are wrong (he might be wrong about that, sure). How should he call them? If the points the original post argues for are not true anymore under PHP 5, and the author doesn’t point that out, the post is wrong. Not ‘almost right’, wrong.

    Sure, assigning a variable would speed up the if/else syntax, but it’s unnecessary when the switch/case syntax can achieve the same thing without populating the namespace you’re in

    I think it just meant that your example is contrived. I think that the switch-case statement is more readable than a string of elseifs, and that the namespace pollution is the real issue, but your example isn’t fair. You could have also used a more concise syntax with the opening and closing brackets in the same line as the expressions or the elses:
    $calc = calculate($var1);
    if ($calc == ‘horse’) {
    // Do this
    } else if ($calc == ‘donkey’) {
    // Do this
    }

    A bit more similar to the switch, isn’t it? Now you could argue that the namespace is a little less polluted, and that the switch is more readable without the syntax or the function getting in the way of your point.

  • http://www.calcResult.co.uk omnicity

    The two most important lessons I have learned about performance are:
    1) It all depends on the exact circumstances
    2) Even if something looks logically simpler, always do a real-world test before changing simply for speed.

    Unfortunatly, I see more awareness of these two rules in the Google article than in the comments here, so my thanks go out to him for having the courage to start an important debate.

  • Dorsey

    Google should focus on their core competency, which is wringing maximum revenue from search and search-related products and services. For them to advise the world on how to improve our source code is well beyond their charter and comfort zone.

    That said, what they’ve written falls into two categories: making code easier to read, and Algorithm Design 101. Any company that performs routine code reviews will come up with many more “improvements” than are on Google’s list. Google did make one valid point that many still haven’t learned, and that is rather than guessing at where the “hot spots” are, use a profiling tool that will actually tell you.