Come on, are really important several milliseconds in the execution of a script if you can save seconds caching the database? Real optimization is not like this Google guy says.

Optimizing PHP: cache and more cache. And don’t use a template system like Smarty, PHP is a template language itself.

What do you prefer, save less than 1 millisecond in the execution of your script or save weeks by writing a maintainable code, using frameworks, etc?

Example:

function do_some_work($data) {
// this is bad, because $data is a
// copy of the original variable
}

function do_some_work(&$data) {
// this is better, because there is no
// copy involved internally, the original
// variable is passed through
}

// $mydata is a big, big array with lots of stuff
do_some_work($mydata);

Just a little mention about number 8 in the list.

8. The include command is not a function and therefore it should not be wrapped in (). It’s also a good thing to use single quotes when handling strings so PHP doesn’t need to look for variables in the string.

Here’s how i had done it
include ‘./some_file.php’;

Any comments or suggestions?

IMHO:

1. Use Opcode cache
2. Cache PHP output
3. If you need to care about much else, you probably shouldn’t be using PHP.

I thought that it wasn’t necessary to call mysql_close(), that PHP automatically calls it for you at the end of your script. Granted, it may be good form to call it, but if it’s being called automatically, how is not calling it affecting PHP performance?

1. Very true. mysql_free_result() can also be useful for larger queries.

2. This is not really PHP specific, but when used correctly [like caching method / function calls or really anything, it can make a very significant difference]

3. This really is specific to Apache. It can also be used to deflate non text/html requests as well, like Javascript, CSS, etc.. which is one reason I love this module so much :-) [http://httpd.apache.org/docs/2.0/mod/mod_deflate.html]

4. Whether it’s local or not doesn’t make much of a difference here… closing the resource when you’re done with it does make sense, though. But you could find yourself chasing your tail finding a bug in your code if you forgot that you closed the connection.

5. I can’t say that I find this to be even remotely true. Persistent connections are great when you have steady traffic to a server, but once your site goes up on digg your connections will dry up fairly quickly and your visitors will be sad. This also goes for high keep-alive settings [for apache]. The remote / local factor really doesn’t make any difference [IMO].

6. This is true… though I’ve found that most people will throw a count() in there, which usually makes an unnoticeable difference in page load time. But if it is another function which does take a while, then you could run into response time issues.

7. Again, this usually makes an unnoticeable difference in page load time. Even then, passing more than one argument to the echo construct is technically faster than concatenation [is some tests I've seen].

8. True, a full path to the file can also be beneficial: /var/www/html/somesite.com/_inc/something.inc

9. I agree… I have a function which I call to return include paths for me, so I might call: import(”file.inc”); which will return the full path to the file if I haven’t called import() with “file.inc” as an argument yet. Otherwise it will return false, telling me that I have already asked for the include path, and therefore already required the file.

10. I agree 100%. Abstracting things into objects can make testing, caching and applying the DRY principle much easier, though. It also makes it much easier for more than one person to work on the files.

11. _Seem_ faster? I don’t think I can recall a time where using this makes a difference [at least the theory of catching your output buffer and purging it all at once]. The server still needs to do everything to create the HTML to send back to the user. Though I have had luck with flush()ing output to a user at certain parts of the script, plus they get their headers sooner.

Thanks for the article :-)