Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39955
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.17 cause and error)
To: internals@lists.php.net
Date: Thu, 14 Aug 2008 03:01:20 -0500
User-Agent: KMail/1.9.9
References: <909776579.20080803142659@marcus-boerger.de> <48A3D475.7040903@lerdorf.com> <1F83E7D6F6F94BE89BA045FE02F89749@pc>
In-Reply-To: <1F83E7D6F6F94BE89BA045FE02F89749@pc>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200808140301.20278.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: larry@garfieldtech.com (Larry Garfield)

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
larry@garfieldtech.com