views:

1242

answers:

2

I have a colleague who is looking into Opt-Code Caching/Zend Acceleration (I've always assumed these are the same thing) for our PHP based application. His Benchmarks appear to indicate that we're NOT seeing a performance benefit if we include our (large) class libraries with require_once, but we DO see the performance benefit when using include_once.

This smells fishy to both of us, but I don't have time to check into our benchmark methodology myself and my colleague has more tolerance for the smell of fish than I do. :)

Has anyone ever run into anything like this? If not, any thoughts on other things that might be causing the appearance of a performance increase by switching from include_once to require_once?

A: 

I can't guarantuee anything as i haven't looked deeply enough into it, but yes, i have seen speed differences between the two. They were never significant enough to me to move to include_once instead of require_once though.

I always assumed the difference was because require_once has to do more work underwater. at least one more potential error to prepare for and handle, and a lot more to do when the file required does not exist.

Kris
+2  A: 

For starters, both calls (require_once and include_once) double-check if a file has not been included before.

So the way they both achieve this is by searching the file in all available paths and by essentially checking if it hasn't been in the mix before etc..

In the background what happens is that they evaluate all the different options (e.g. multiple include_path's, etc.) and then by creating the realpath from this abreviated form they create a unique identifier. There is only one and the same path - not two.

This is already not the fasted thing on the planet and generally happens on each request with PHP. Then add another expensive operation which is the stat when it creates what I called the realpath (realpath, because it's sort of what realpath() does) to check if the file exists.

Correct me if I am wrong, but APC has optimizations especially for this case.

So anyway - now on to the difference between require_once and include_once, which is that require_once evaluates the file (for low-level parse errors, etc.) when it includes it. This is an additional check which you can get rid off if you have enough QA in place that a parse error can never sneak into an include.

It's just tricky to find otherwise. :-)

(Something to consider: You could develop with require_once and replace all calls with include_once when you deploy.)

As for an opcode cache - I'd recommend APC. It's been discussed on stackoverflow before. Personally, I am/we are using it for a while (we roughly handle 100k visitors/day with 3 frontends and 1 backend) and we are very happy. APC is also optimized for the require_once/include_once madness.

A pretty cool side-effect is that APC also allows you to store PHP variables in memory - sort of persistant, etc..

A couple additional pointers:

  1. A lot of people claim to speed up any application with __autoload.
  2. With an opcode cache, avoid conditional require_once/include_once (e.g. in loops or in control-flow).
  3. Some people say that /absolute/path/to/file.php in include_ or require_once is faster than relying on the include_path.
  4. The order of the paths in your include_path matters as well.

Hope that helps.

Till
"if you have enough QA" ... you're pretty funny ;)
Alan Storm
I just tested require() vs. require_once() in a 100-iteration loop. The included file defines a small class with 1 method.With require, the parent script takes 0.02 sec to run.With require_once, the parent script takes 0.005 sec to run.Even still, few scripts are ever going to include enough files for it to make any different. Basically, this is about the LAST optimization we need to worry about.
dirtside
@dirtside: Please share your benchmark code. :)
Till