Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.56 cause and error)
To: internals@lists.php.net
Date: Thu, 14 Aug 2008 01:37:28 -0500
User-Agent: KMail/1.9.9
References: <909776579.20080803142659@marcus-boerger.de> <200808140027.53442.larry@garfieldtech.com> <48A3C45D.10400@lerdorf.com>
In-Reply-To: <48A3C45D.10400@lerdorf.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200808140137.28106.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: larry@garfieldtech.com (Larry Garfield)

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"?)

Even then, every benchmark I've seen for Drupal (the system I work on) still 
gives a several-fold increase in runtime performance with an opcode cache, so 
I am not super worried about eeking out every last CPU cycle.  We also by 
nature have to support user-pluggable modules, which cannot be statically 
included.

There's also memory usage to consider.  In our testing, conditional includes 
sliced 25% off of the memory usage when not using an opcode cache and had no 
noticeable effect when using an opcode cache, so that's still a big win for 
larger code bases.  We're working at making even more code conditionally 
included in the next version for that exact reason.

In any case, the point I am making is that saying "well, don't use conditional 
includes and namespaces" or "don't use functions and namespaces" is a 
non-option.  Either of those pretty much guarantees that we (Drupal) will 
never be able to use namespaces in practice.  

-- 
Larry Garfield
larry@garfieldtech.com