Re: beginning plannings for PEAR for PHP6

Rasmus Lerdorf wrote:
> Gregory Beaver wrote:
> > Rasmus Lerdorf wrote:
> > > Justin Patrin wrote:
> > > > On 10/14/06, Gregory Beaver <greg@xxxxxxxxxxxxxxxxx> wrote:
> > > > > #2 libraries need to be opcode cache-friendly (require instead of
> > > > > require_once, or a class loader)
> > > > Could you explain more about this (or point us to some resources on
> > > > it)? This is the first I've heard of require_once not being ok to use.
> > > > Why in the world would using _once break an opcode cache?
> > > >
> > > > Ok, looking myself I found:
> > > > http://www.phpinsider.com/smarty-forum/viewtopic.php?t=7674&sid=a4a5feb6971f5dd4201d34aa6327d4d3 
> > > >
> > > >
> > > > which links to a post by Rasmus explaining this somewhat:
> > > > http://marc.theaimsgroup.com/?l=php-dev&m=113883455711935&w=2
> > > > and a post to the lighttpd forum:
> > > > http://forum.lighttpd.net/topic/864
> > > >
> > > > Rasmus' message says he's looking into ways to fix this and tihs was
> > > > back in Feb. Perhaps he's fixed it by now? (I'm not subscribed to
> > > > php-internals, so...)
> > > We don't have a decent fix.  And it isn't that it breaks an opcode
> > > cache, just that it isn't very efficient because we end up with a
> > > useless open() syscall.  In general you are way better off declaring
> > > your dependencies up front and avoiding include spaghetti.  No matter
> > > what we do, if a script makes 5 calls to require_once on the same file
> > > that is always going to be way slower than a better organized
> > > application that makes a single call to require.  We should be
> > > encouraging the latter, not the former. 
> > Hi Rasmus,
> >
> > Since PEAR can't reliably load dependencies in libraries without some
> > kind of class loading, are you saying that you like the
> > autoload/class_exists('classname', true) solution I proposed, or that
> > something else would be better?
>
> I personally prefer completely clean libraries that don't do any runtime 
> checks at all.  Any tricks you add will cause nasty performance 
> penalties.  autoload is especially nasty because you are forcing things 
> out of the compiler down into the executor which again kills performance 
> under an opcode cache.

The problem is that right now we need to think about users with and 
without an opcode cache. If APC is bundled with PHP6, which seems likely 
at this point, this situation will slant towards opcode cache enabled. 
However, people running on hosters may till find that their available 
memory is too limited (or that APC is even disabled because of this).

Especially with many applications going AJAX, meaning short requests 
that do much less and therefore touch a lot less code, it seems to make 
no sense to load all dependencies first. In that way __autoload() is 
kind of cool. Then again if you have the memory and you have an opcode 
cache, then you rather not want any conditional code loading at all. It 
just screws with the opcode cache and it probably does not buy you any 
performance either.

Anyways, unfortunately not even Stig can remember why he wanted to use 
include path magic over dirname(__FILE__) that I proposed back when we 
did not have a real standard yet.

I guess one of the big advantages of the include path based solution we 
have right now is that it enables people to easily replace some files in 
PEAR packages without having to modify the original package at all. 
However I do not think many people use this.

regards,
Lukas