Published by Fabian on 20 Apr 2009 at 02:24 pm
More Performance for a symfony Site
symfony project development at the moment focuses on finding and eliminating more performance issues, as this was high on the whish list. The symfony blog has two postings about recent enhancements.
While being at it i noticed a common 5ms and highly disc bound delay that is included in every call.
It is sfProjectConfiguration#getAllPluginPaths() which returns an array of all plugins and their respective location on the file system. Its basically a sfFinder call that scans a few directories. But that costs. And it is done on every call. But usually the plugins do not change while a site is live, do they?
Here my inofficial enhancement of this. You can easily use this. Just put it into your config/ProjectConfiguration.class.php and you are done:
public function getAllPluginPaths(){ $cacheFile = sfConfig::get('sf_cache_dir').'/all_plugin_paths.cache'; if (is_readable($cacheFile)) { return unserialize(file_get_contents($cacheFile)); } $allPluginpaths = parent::getAllPluginPaths(); file_put_contents($cacheFile, serialize($allPluginpaths)); return $allPluginpaths; }
NiKo on 20 Apr 2009 at 9:48 pm #
Neat. Why isn’t this patch included into sf core?
Leandro on 20 Apr 2009 at 9:48 pm #
These types of improvements would not be part of a task such as freeze, where it is assumed that neither the plugins or directories are going to change?
naholyr on 21 Apr 2009 at 8:16 am #
I’d even not call serialize/unserialize but directly var_export(true) :
I think that while we are on the performance subject, we should avoid each time we can to use eval or serialize
Fabian on 21 Apr 2009 at 2:41 pm #
I think this is a bit of a corner case and depends on if this hurts you.
Adding more and more caching can get out of control, so I would rather not include it in core
@naholyr
Great idea. you are right, much better than serializing