On Thu, Nov 3, 2011 at 4: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... You mixing up one of my personal objectives* with the poster's objective** (which I also share). * making the class map based vs convention based performance discussion moot, making sure more people will standardize around PSR-0 ** making sure there is a autoloader in php that follows a convention that people actually use, and further standardized how such a basic thing is done in php projects in the wild. > > > > 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/ > >> > > >
