Re: [APC-DEV] APC and autoloading

David Zülke wrote:

Is it indeed accurate that APC doesn't accelerate _anything_ if a class is loaded via autoloading? I know it doesn't work well with _onces, but PHP 5.2 fixes that from what I understand.

When you use autoloading, apc does indeed cache your opcode streams. But the compiled files only contain the skeletons of the classes which are initialized at runtime. This pulls in a bit of uncertainty about whether a parent class is loaded or not, unlike the include() scenario. If you end up with a scenario where one file includes a file containing a class without including the file containing its parent class, and then yet another includes them in proper order, it becomes impossible to cache the former file. And then apc just filters out those files.

I always thought autoloading was the way to go, since it's not doing a _once (for obvious reasons), and it's only loading stuff on demand, so I assumed it to be the fastest of all possible solutions.

On-demand loading brings in a new evil. So while you're running through a chunk of code, you suddenly hit a roadblock where the parent's not there in the class table. So you stop the entire engine and end up hitting the apc cache for the file. Eventually your compiler and runtime loops start to get nested too deep. Generally speaking, the more deterministic you make your include() calls without any runtime if(){} blocks or dynamic __autoload() calls, the faster the code is likely to be. But that said, there are cases where __autoload could be beneficial, where a single script is responsible for a wide variety of functionality (say, expose a SOAP service) and including them all at the top just doesn't make sense. But in a general case, __autoload is likely to hit your performance, just like require_once, maybe even more. I'll do a bit of benchmarking sometime today and confirm the theory. Cheers, Gopal -- The difference between insanity and genius is measured by success