It's also possible to speed up your application by optimizing the code itself. This section offers some insight regarding how to do that.
18.6.1. Core Compilation
Loading ten files requires more I/O operations than loading one long file, especially on slow disks. Loading a very long file requires more resources than loading a smaller file — especially if a large share of the file content is of no use for the PHP parser, which is the case for comments.
So merging a large number of files and stripping out the comments they contain is an operation that improves performance. Symfony already does that optimization; it's called the core compilation. At the beginning of the first request (or after the cache is cleared), a symfony application concatenates all the core framework classes (sfActions, sfRequest, sfView, and so on) into one file, optimizes the file size by removing comments and double blanks, and saves it in the cache, in a file called config_core_compile.yml.php. Each subsequent request only loads this single optimized file instead of the 30 files that compose it.
If your application has classes that must always be loaded, and especially if they are big classes with lots of comments, it may be beneficial to add them to the core compile file. To do so, just add a core_compile.yml file in your application config/ directory, and list in it the classes that you want to add, as in Listing 18-22.
Listing 18-22 - Adding Your Classes to the Core Compile File, in frontend/config/core_compile.yml
- %SF_ROOT_DIR%/lib/myClass.class.php
- %SF_ROOT_DIR%/apps/frontend/lib/myToolkit.class.php
- %SF_ROOT_DIR%/plugins/myPlugin/lib/myPluginCore.class.php
...18.6.2. The sfOptimizer Plug-In
Symfony also offers another optimization tool, called sfOptimizer. It applies various optimization strategies to the symfony and application code, which may further speed up the execution.
The symfony code counts many tests that rely on configuration parameters — and your application may also do so. For instance, if you take a look at the symfony classes, you will often see a test on the value of the sf_logging_enabled parameter before a call to the sfLogger object:
if (sfConfig::get('sf_logging_enabled'))
{
$this->getContext()->getLogger()->info('Been there');
}Even if the sfConfig registry is very well optimized, the number of calls to its get() method during the processing of each request is important — and it counts in the final performance. One of the sfOptimizer optimization strategies is to replace configuration constants by their value — as long as these constants are not subject to change at runtime. That's the case, for instance, with the sf_logging_enabled parameter; when it is defined as false, the sfOptimizer transforms the previous code into the following:
if (0)
{
$this->getContext()->getLogger()->info('Been there');
}And that's not all, because an evident test like the preceding one also gets optimized to an empty string.
To apply the optimizations, you must first install the plug-in from http://trac.symfony-project.org/wiki/sfOptimizerPlugin and then call the optimize task, specifying an application and an environment:
> php symfony optimize frontend prod
If you want to apply other optimization strategies to your code, the sfOptimizer plug-in might be a good starting place.