Re: [Coding Standards] Loading all files at once

From: Date: Mon, 09 Jul 2007 21:54:54 +0000
Subject: Re: [Coding Standards] Loading all files at once
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-47313@lists.php.net to get a copy of this message
Pádraic Brady wrote:
I think part of the problem is where is your __autoload() function? What form do you envisage it taking? __autoload() definition, Autoload class (much slower by the way) or reliance on an SPL registered autoload function? There will be a function named PEAR2_Autoload, it may be SPL registered i haven't looked into that
If you're relying on the user to define this it's almost certainly going to add issues - you cannot expect users to accept PEAR2 running from their application level _autoload() defines. There is no guarantee they will ever implement the PEAR style classname to file location convention. the PEAR2 function can easily check that the name starts with PEAR2 and only run on those
Also __autoload() does conflict with the stated purpose of being opcode cache friendly - the last thing I want to see when running an opcode cache is any significant number of class files being loaded using it.That should be qualified by noting the impact of __autoload() on an opcode cache is highly dependent on the nature of the class/functions being cached. A few classes not being 100% cached (file-only caching) is unlikely to register a blip anywhere on a performance audit. If your using apc you would just use allfiles.php or an optimized allfiles.php instead of autoload
Solution to the stated goals? I'm not sure there can be one capable of meeting everyone's needs. The present system would basically gut anyone on shared hosting with that level of file loading. I know PHP6 will have a built in opcode cache - and that will be incredibly sexy. Until then however... I can't see PEAR2 reaching out to shared hosting users in this form. It would be a no-brainer to spot PEAR2's impact from even a cursory examination of an applications performance without an opcode cache. See Travis' benchmarks... Those of us who code to a non-opcode platform have worked to similar numbers for a long time. The shared hosters developers are the people who have the most problem with the current setup and its requirement on setting the include_path, so I would say the majority of them would welcome ease of use or performance any day.
Obviously we can't meet everyones needs, but we do want a solution that is better then the current one. An allfiles.php approach might not be that, but obviously status quo isn't any better either. -josh

« previous php.pear.dev (#47313) next »