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 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
