Marcus Boerger wrote:
Hello Rasmus,
Thursday, August 14, 2008, 7:36:29 AM, you wrote:
Larry Garfield wrote:
I would also note that "include up front and have a good autoload scheme"
works great if you are writing all classes. If you're trying to use
namespaces and functions, there is no autoload. That makes the autoload
argument moot, and pre-loading everything up front can get ridiculously
expensive in large systems, and even then you don't always know what to load
up front. (Think anything that accepts plugins.) So an answer of "well if
it throws a warning when you do that, don't do that" is simply not realistic
in practice.
With an opcode cache, it is actually often more efficient to load
everything up front even if you aren't using it all on any given
request. By using autoload or other conditional mechanisms you lose the
function and class caching mechanism provided by the opcode cache
because you have now pushed the creation of these to the executor
instead of letting the opcode cache cache them for you.
And assuming your include_path setting and your include hierachy is
clean so you don't have any or at least only minimal per-include stat
overhead, whether you include 1 or 20 files on a request isn't a big
deal since they are all going to be in memory anyway.
See, this is something I fail to understant/accept. With all the crappy
delayed inheritance and whatnot dynamic feature of the language it only
seems fair that we develop apc in a way that it checks whether a class
always gets created from the same file. Or at least we should provide a
flag where apc would evaluate __autoload calls only once and then caches
the results. If someone wants to screw up, it is their fault, erm their
tradeoff, they'd simply get a much slower execution time as they wouldn't
be able to use that optimization.
We already do that. See the report_autofilter check in APC.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
