What's the performance cost of Magento's fallback mechanism?

Question

Magento has a fallback mechanism that helps prevent errors and theming problems by checking for the existence of expected files through a defined set of paths. It's implemented like this:

/**
 * Check for files existence by specified scheme
 *
 * If fallback enabled, the first found file will be returned. Otherwise the base package / default theme file,
 *   regardless of found or not.
 * If disabled, the lookup won't be performed to spare filesystem calls.
 *
 * @param string $file
 * @param array &$params
 * @param array $fallbackScheme
 * @return string
 */
protected function _fallback($file, array &$params, array $fallbackScheme = array(array()))
{
    if ($this->_shouldFallback) {
        foreach ($fallbackScheme as $try) {
            $params = array_merge($params, $try);
            $filename = $this->validateFile($file, $params);
            if ($filename) {
                return $filename;
            }
        }
        $params['_package'] = self::BASE_PACKAGE;
        $params['_theme']   = self::DEFAULT_THEME;
    }
    return $this->_renderFilename($file, $params);
}

As a Magento theme developer you have two options: You can add as little as possible to your new theme and depend on the fallback, or you can copy everything from the fallback theme into your new theme and modify that (in which case the fallback has to iterate over fewer files before finding its target). The former approach is recommended. The latter is not.

Copying those files is certainly messy, but on the other hand it seems the fallback should be fairly expensive, particularly if (being a good, pithy coder) you make sure as many files fall back as possible. So I find myself wondering if a Magento site will perform better if I take steps to minimize the amount of fallback that happens.

I've searched the web, but haven't found any information about this question, and I'm not yet familiar enough with Magento to profile the fallback myself. Is there any information about the actual performance cost of this fallback mechanism?

Answer 1

The performance cost is 37.

Less snarkily: Your question is, unfortunately, unanswerable. While there's (obviously) a performance cost to stating those files and directories, Magento (and any LAMP application) will hit performance bottlenecks due to SQL overhead and CPU much sooner than it will due to other factors. Performance tuning of modern web applications tends not to happen on the the application level, but instead treating the application as an unchangeable blob and purchasing/configuring the best possible hardware setup.

If anyone has benchmarked Magento with fallback on or off, they haven't shared the information publicly.

Answer 2

There is a performance cost, but like Alan said, it will depend on your server architecture more than the application.

It's worth noting that Magento has a fallback mechanism for code files too, which could also be costing you precious milliseconds. Unlike the theme fallback, there's a workaround for this. Magento calls it a "compiler".

Normally, upon a request to load a class, the Autoloader looks in four locations to find the appropriate PHP file: app/code/local, app/code/community, app/code/core and finally lib. Useful if you want to overload certain core code with your own version, but slow because of the huge amount of classes scattered around the filesystem.

So the Magento Compiler ensures that the Autoloader only has to look in includes/src and will open less files.

In theory, this should not make much of a difference, because your server should be caching these files, but you'll have to read the full article to understand why it isn't quite so cut and dry.

http://www.byte.nl/blog/should-i-use-the-magento-compiler

Anecdotal evidence: In a store with a large number of 3rd party modules, we saw the time-to-first-byte drop from ~2 seconds to ~1.6 seconds, just by enabling the compilation.

Word of warning: Some 3rd party modules aren't built correctly, and they cause the entire store to break when compilation is enabled. Usually this is because they are trying to include_once or require_once some file with a relative path, and it won't work because the file lives in a different directory when compilation is enabled.