Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <1F83E7D6F6F94BE89BA045FE02F89749@pc>
To: <internals@lists.php.net>
References: <909776579.20080803142659@marcus-boerger.de> <200808140027.53442.larry@garfieldtech.com> <48A3C45D.10400@lerdorf.com> <200808140137.28106.larry@garfieldtech.com> <48A3D475.7040903@lerdorf.com>
Date: Thu, 14 Aug 2008 10:08:23 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

>> 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
>

Hi,

This is why it pays to have two automated distribution models. For 
deployment with no opcode cache, and for development/version control, an 
autoloader using a class map is most practical.

An automated packer can take all classes and functions (or part of them in 
common use) and put them in the bootstrap file for opcode deployment, 
leaving only the less common to autoload.

(And which makes the fact we can now have multiple namespaces in one file 
really important)

Regards,
Stan Vassilev