Re: Inconsistencies in 5.3

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