On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > Can I make a point here. > > Why the heck are we caring about the performance of the autoloader at > all here? The filesystem operations necessary (at least the stat() > call) will greatly dominate any string function. And considering that > even the biggest framework only has perhaps a few hundred classes, > you're talking about incredibly small performance gains here. Even if > you save a microsecond in string operations (try it, even in PHP the > string operations can be done in around 10 or 20 microseconds), after > all classes are loaded you're only talking about a 1 or 2 milliseconds > of gain in the application. > > I'm not saying that we shouldn't try to save time where we can, but > given the controversial nature of this addition, I don't think that a > micro-optimization (which is what this really is) should be used as a > justification for why it should be included. It's not like we're > talking about implementing a computationally difficult task into C > (such as a cryptographic algorithm) where putting it into C would > create a huge performance gain. We're talking about implementing a > function which already is dominated by non-computational overhead into > C to save a few milliseconds. The number of instances that will > benefit from such an addition are incredibly small. Saving 2 > milliseconds on an application (that likely takes hundreds of > milliseconds to render) would require a huge number of requests to > amortize into an actual measurable benefit. And those that do benefit > would have access to their server farm to add the pecl extension > anyway. So there's really no practical performance gain to the > community as a whole, hence confirming that this is a > micro-optimization. > > Personally I feel that this does not belong in the core (especially > not yet as with the inconsistencies). > > But that's besides the point. I just want to emphasize the point that > performance should not be a criteria for justifying it going into the > core... > > Anthony Basically, theres approx a dozen of the most recognised PHP libraries that are advocating the use of a generalised class mapping standard.
This is great, and allows switching between projects very seamless as there's no additional learning curve. while(consistency) learning_curve--; If library vendors are implementing their own custom autoloading structure/mechanism it's very counter-productive to the PHP eco-system. The point of PSR-0 is to create a standard to allow compatibility between vendor libs such as ZF/Symfony/PPI. With the point to being included in /ext/spl/; is to give a sense of "justification" of this standard and a base in which to push forward. It's also giving existing lib vendors to easily switch to a well-built autoloading mechanism bundled with PHP rather than relying on third-party code to provide that. Additionally the small performance boost but including SplClassLoader is not driven by the speed benefit but by the community/library benefit. This appears to be the general consensus of PSR-0 and my opinion on the matter. Regards, Paul Dragoonis. > > > On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke <a...@ez.no> wrote: >> On Thu, Oct 27, 2011 at 4:30 AM, Laruence <larue...@php.net> wrote: >> >>> 2011/10/26 André Rømcke <a...@ez.no>: >>> > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < >>> > guilhermebla...@gmail.com> wrote: >>> > >>> >> Hi internals, >>> >> >>> >> For all those interested, I have updated the RFC with better >>> >> explanation, included example implementation and also example usage. >>> >> If you have any other wishes, doubts, etc, feel free to ask on this >>> >> thread and I'll quickly answer here and also update the RFC >>> >> accordingly. >>> >> >>> > >>> > >>> > As sent to the PHP-SWG list, a small change / addition to PSR-0 would >>> > simplify the matching considerably. >>> > >>> > If this rule: >>> > * Each “_” character in the CLASS NAME is converted to a >>> > DIRECTORY_SEPARATOR. The “_” character has no special meaning in the >>> > namespace. >>> > >>> > is changed to >>> > * Each “_” character in the CLASS NAME and NAMESPACE is converted to a >>> > DIRECTORY_SEPARATOR. >>> There is a internal autoloader in >>> Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup), >>> in it the T_NS_SEPARATOR will convert to be "_", then convert to be >>> DIRECTORY_SEPARATOR. >>> >>> thanks >>> >> >> >> As mentioned by others this will have to go into a new PSR standard as >> PSR-0 was accepted 2 years ago. >> >> And assuming that a C implementation will greatly out-weight the reduced >> amount of str functions in terms performance we should not block this >> process to get it into 5.4 by taking up off-topic subjects like mentioning >> things not part of PSR-0. >> >> But! >> >> The implementation proposal (rfc) should be adjusted to be >> forward compatible, including support for several namespaces pr instance >> (mention by several on PSR mailing list) imho. >> >> Possible example (additional arguments can be added later when more >> features are added, aka a PSR-1 mode): >> >> new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) ); >> >> >> Or something like this (if we want the options to be an array): >> >> new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' => >> '/path/to/doctrine' ) ) ); >> >> >> For documentation and argument validation, imo the former approach would be >> better. >> So what is the status here? thread has been silent for a while. >> >> >>> > >>> > Or a strict mode is added to enable that, then you'll reduce 6 string >>> > function to 2, and still have backward support for PEAR class naming(w/o >>> > namespace). >>> > >>> > >>> > >>> > >>> >> The url for the RFC is: https://wiki.php.net/rfc/splclassloader >>> >> >>> >> Cheers, >>> >> >>> >> On Mon, Oct 24, 2011 at 7:55 PM, David Coallier <dav...@php.net> wrote: >>> >> >> >>> >> >> Could you open a FR at bugs.php.net and attach the patch to it >>> please? >>> >> >> Could be easier to track (and the # to the RFC too :) >>> >> >> >>> >> > >>> >> > Yeah I'll do that once I have the tests adjusted and once I know the >>> >> > patch actually works as expected. >>> >> > >>> >> > -- >>> >> > David Coallier >>> >> > >>> >> > -- >>> >> > PHP Internals - PHP Runtime Development Mailing List >>> >> > To unsubscribe, visit: http://www.php.net/unsub.php >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Guilherme Blanco >>> >> Mobile: +55 (11) 8118-4422 >>> >> MSN: guilhermebla...@hotmail.com >>> >> São Paulo - SP/Brazil >>> >> >>> >> -- >>> >> PHP Internals - PHP Runtime Development Mailing List >>> >> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> Laruence Xinchen Hui >>> http://www.laruence.com/ >>> >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
