Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39953
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: <48A3D475.7040903@lerdorf.com>
Date: Wed, 13 Aug 2008 23:45:09 -0700
User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008071516)
MIME-Version: 1.0
To: Larry Garfield <larry@garfieldtech.com>
CC: internals@lists.php.net
References: <909776579.20080803142659@marcus-boerger.de> <200808140027.53442.larry@garfieldtech.com> <48A3C45D.10400@lerdorf.com> <200808140137.28106.larry@garfieldtech.com>
In-Reply-To: <200808140137.28106.larry@garfieldtech.com>
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)

Larry Garfield wrote:
> On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf 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.
>>
>> -Rasmus
>
> For better or worse 99% of the code I write runs on systems without an opcode
> cache 99% of the time so that's what I optimize for.  That it is apparently
> impossible to optimize for both opcode caching and non-opcode caching
> environments at the same time (the former hates conditional include, the
> latter loves it) is a problem in itself, although I will be honest that I
> have never fully understood the reasons for it.  (Doesn't the opcode cache
> just recognize "oh yeah, file /foo/bar/baz.php, I've got that parsed already
> I'll just add that to the runtime environment"?)

No, it also takes all top-level functions and classes and caches the 
created functions and classes in shared memory and modifies the cached 
opcodes to not need to create these at execution time.  However, it 
obviously can't do this if the execution context is required in order to 
know whether the function or class should exist on that request, so 
whenever you do any sort of conditional function or class definition you 
lose this level of caching.

-Rasmus