from my experience with tight optimization, autoload is not always fastest either. if you include some files for all requests (or 98% of them) its faster to do it with a bunch of req ince with abs path.

also difference between abs and rel increases when you have more dirs on the include path .. that is tricky as depends on env so better check prod setup … could be worth checking the numbers

cheers

In fairness the intention was to see how quick an include_once()/require_once() is compared to an include()/require() statement when the statement is including the same file more than once – perhaps I should have been more clear about that at the outset. I wouldn’t assume that a single include_once()/require_once() statement is quicker than a single include()/require() statement.

But fair enough – I’ve taken the bait and tweaked the tests – results are above. This time each file was only included/required twice and Apache Bench was used to invoke the actual scripts.

@Greg:

Why does this matter? Well, I’d rather know than guess and the debate has been around for years. My conclusions are of course subjective, and (fancy charts notwithstanding) the empirical evidence is that include_once() and require_once() are the quickest – not the slowest.

My conclusions (the use of relative paths and that require_once()/include_once)() are quicker) are my own and I would hardly call them recommendations.

@Everyone:

What about some code to contradict/confirm these findings?

Why does this even matter? You make some assertions with fancy charts, and then proceed to recommend that people actually try what is empirically the slowest options. Please re-run the benchmarks using proper benchmarking methodology and you will see the drastic errors in your ways.

For a start, perhaps you could steal Paul M. Jones’s script for benchmarking different frameworks:

http://code.google.com/p/web-framework-benchmarks/source/browse/trunk/_siege/siege.php

Related reading:

http://paul-m-jones.com/archives/421

I agree – the test set up is totally artificial. However I wanted to look at the PHP functions themselves rather than start benchmarking the Apache server. The tests on http://markmail.org/message/hxzqcgrzrh6szce4 would be interesting to revisit today.

@Jaik:

I wouldn’t be too bothered with the performance differences myself – as Greg points out including the same trivial file 10,000 times hardly demonstrates anything tangible. I prefer to code in such a way that a file only ever needs to be included once anyway (by encapsulating in a class or a function).

@Sjan:

I didn’t look at __autoload() for the simple reason that I avoid using it. I did use it earlier in the Tina framework, but I found that I ended up colliding with another plugin author’s __autoload() function. In an environment where everyone is playing nicely with each other I would like to use __autoload(), but in Wordpress that doesn’t happen!

First of all, you can’t benchmark anything properly using microtime() in PHP, the only way to accurately benchmark is to use siege, or its slightly less accurate cousin apache benchmark (ab)

I would also like to point out that no one is including a file over and over again that contains a single variable assignment. People are including libraries with class or function code. If you want to see a benchmark of ways of including code that also addresses the comparison of including versus stuffing it all into one file (and this one against PHP 5.3 in its pre-alpha stages), try

http://markmail.org/message/hxzqcgrzrh6szce4

for a sample. Disclaimer: I haven’t tried this benchmark in a few years, and there have been some further optimizations of PHP itself, and of how APC handles *_once. However, the performance difference between include and include_once is not the only reason to avoid using require_once/include_once, tangled circular *_once references (like in the HTML_QuickForm package) can render a library unoptimizable by APC.

I think you’ll find that your numbers are less surprising when it turns out that they are wrong

By the way, try replacing your for loops with do{}while (–$i); where $i is initialised with the number of iterations. For some reason, do-while incurs much less overhead than for and still less than while. Or so it seems.