On Thursday 14 August 2008 2:08:23 am Stan Vassilev | FM wrote:
> >> 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

Hm, I see.  So you still get the cached compiled opcodes, but not the 
cached "linking".  (To use C++ terminology, which I'm sure is technically 
inaccurate in this case.)  Thanks.

> 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

Not looking to start a flame war, really, but how do the above opcode concerns 
impact Phar?  (I mention that here because it was discussed as a potential 
alternative to multiple namespaces per file to avoid the many-stats problem.)

-- 
Larry Garfield
[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to