For better or worse 99% of the code I write runs on systems without an opcode
cache 99% of the time so that's what I optimize for. That it is apparently
impossible to optimize for both opcode caching and non-opcode caching
environments at the same time (the former hates conditional include, the
latter loves it) is a problem in itself, although I will be honest that I
have never fully understood the reasons for it. (Doesn't the opcode cache
just recognize "oh yeah, file /foo/bar/baz.php, I've got that parsed already
I'll just add that to the runtime environment"?)
No, it also takes all top-level functions and classes and caches the created functions and classes in shared memory and modifies the cached opcodes to not need to create these at execution time. However, it obviously can't do this if the execution context is required in order to know whether the function or class should exist on that request, so whenever you do any sort of conditional function or class definition you lose this level of caching.
-Rasmus
Hi,
This is why it pays to have two automated distribution models. For deployment with no opcode cache, and for development/version control, an autoloader using a class map is most practical.
An automated packer can take all classes and functions (or part of them in common use) and put them in the bootstrap file for opcode deployment, leaving only the less common to autoload.
(And which makes the fact we can now have multiple namespaces in one file really important)
Regards,
Stan Vassilev