Re: beginning plannings for PEAR for PHP6

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.

-Rasmus