(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/
没有评论:
发表评论