found as Matthew did that performance was actually degraded by trying to
cut out the repeated calls. In the end I found that by storing the class
paths in APC shared memory I was able to gain some performance. The
problem being that not everyone has APC installed and many PHP devs
still haven't even heard of PECL.
Take a look at the blog post I wrote about it:
http://codenaked.org/archives/4-A-faster-Zend_Loader.html
Later,
Matthew.
Matthew Ratzloff wrote:
> Matthew: Out of curiosity, how much performance improvement can be expected
> in the final 1.7 release for any of the many "hello world"-style benchmarks
> out there?
> -Matt
>
> On Fri, Oct 24, 2008 at 8:23 AM, Matthew Weier O'Phinney
> <matthew@zend.com>wrote:
>
>
>> -- 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/
>>
>>
没有评论:
发表评论