I couldn't agree more with Anthony. In conjunction with that, I would continue to question the full benefit to the community. How many existing code bases/frameworks out there would implement this in favor of their existing solution?
Will On Nov 3, 2011, at 11:19 AM, Anthony Ferrara 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 > > > 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 >
