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