Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39962
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <48A460F1.4070704@lerdorf.com>
Date: Thu, 14 Aug 2008 09:44:33 -0700
User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008071516)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
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> <486246746.20080814120429@marcus-boerger.de>
In-Reply-To: <486246746.20080814120429@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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