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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
