Re: [fw-core] Caching feature of Zend_Loader

-- Stefan Gehrig <gehrig@ishd.de> wrote
(on Friday, 24 October 2008, 05:07 PM +0200):
> Thanks a lot for this information.
> I added the procedure you described below and it's working quite well.
> Is there an intended reason that the pluginIncludes.php includes
> include_once-statements with the full path given and other ones with just
> the include_path-related path to a file?

Yes -- because we can't get the full path without doing class
reflection, which is expensive.

> The current implementation just caches files that are required within
> systems using the Zend_Loader_PluginLoader while the former
> implementation did cache all classes going though the
> Zend_Loader::loadClass() which should have (theoretically) improved
> performance on loading model classes, controller classes and so on.

"Theoretically" is the operative word here. In practice, it degraded
performance. Trust me on this one; I've been running benchmarks all
week. :)

> Wouldn't performance in general benefit from caching a hashtable/array
> CLASSNAME => INCLUDE_PATH? This would avoid that Zend_Loader has to search
> for the correct file every time a class is requested.
> Just a thought - I didn't try something like that.

This is a feature I'm considering adding to Zend_Loader::loadClass().
ezcomponents and PEAR2 either do this already or plan to do so. If done,
it will operate very similarly to the current PluginLoader include file
cache, however, as it's easier to maintain, and is opcode cache
friendly.

> Thanks again for your comments below.
>
> Best regards
>
> Stefan
>
>
> -----Ursprüngliche Nachricht-----
> Von: Matthew Weier O'Phinney [mailto:matthew@zend.com]
> Gesendet: Freitag, 24. Oktober 2008 16:33
> An: fw-core@lists.zend.com
> Betreff: Re: [fw-core] Caching feature of Zend_Loader
>
> -- Stefan Gehrig <gehrig@ishd.de> wrote
> (on Friday, 24 October 2008, 03:20 PM +0200):
> > why has the caching feature for the Zend_Loader been removed in trunk?
> > Yesterday I made an svn update and was excited about this feature - it
> > really sped things up noticeably on my Windows dev machine (IIS). After an
> > update this morning the caching was gone again... Why?
>
> It's been moved to the PluginLoader.
>
> I did a large number of benchmarks, and discovered that in most cases,
> the original implementation I checked in actually *degraded*
> performance.
>
> So, I removed the functionality from Zend_Loader, and went to the real
> source of the bottle neck: the PluginLoader. What I determined was that
> if the PluginLoader can bail early because a matching class exists, we
> can bypass isReadable checks and include_once calls entirely. The
> new functionality works like this:
>
> // In your bootstrap:
> $pluginIncFile = APPLICATION_PATH . '/../data/pluginIncludes.php';
> if (file_exists($pluginIncFile)) {
> include_once $pluginIncFile;
> }
> Zend_Loader_PluginLoader::setIncludeFileCache($pluginIncFile);
>
> This functionality appends an include_once statement to the given file
> each time a matching plugin is found (but only if the file isn't already
> present). You then make sure you include that file early in your
> bootstrap. The solution is very opcode cache friendly, and completely
> opt-in; use if you want, but you can ignore it if you want as well.
>
> In my benchmarks, this approach presented the single biggest jump in
> performance of any thing else I tried; it presented a 64% performance
> gain in a real-world application that was plugin heavy (form elements,
> decorators, validators, and filters; view helpers; custom plugin loading
> for other resources).
>
> --
> Matthew Weier O'Phinney
> Software Architect | matthew@zend.com
> Zend Framework | http://framework.zend.com/
>

--
Matthew Weier O'Phinney
Software Architect | matthew@zend.com
Zend Framework | http://framework.zend.com/