Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Thu, 14 Aug 2008 12:04:29 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <486246746.20080814120429@marcus-boerger.de>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
In-Reply-To: <48A3C45D.10400@lerdorf.com>
References: <909776579.20080803142659@marcus-boerger.de> <48A36617.5010803@lerdorf.com> <D2E02683-76AF-43F9-8EFE-7BDB297F8BA8@pooteeweet.org> <200808140027.53442.larry@garfieldtech.com> <48A3C45D.10400@lerdorf.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: helly@php.net (Marcus Boerger)

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