# SplClassLoader

- Thread: https://externals.io/message/56031
- Original archive: https://news-web.php.net/php.internals/56031
- Started by Will Fitch on 2011-11-03T15:27:29+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #56031 — Will Fitch — 2011-11-03T15:27:29+00:00

URL: https://externals.io/message/56031#56031

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



> 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
> 
> 
> 
> > […]