#Giving thanks for speed
Welcome to the Lithium thanksgiving day edition of the hello world benchmarks written by [Paul Jones](http://paul-m-jones.com/?p=421). Paul ran several tests over the past few years to compare the pure speed of the dispatch cycle in a few major frameworks. Others have tried to duplicate his benchmarks for their own, but Paul's methodology and approach are second to none, in addition to being publicly documented and independently reproducible.
There are several reasons I worry about pure speed. As Paul points out, its the maximum responsiveness you will ever get from your framework. Some will say that pure speed does not matter since in a production environment, you end up caching most of the request, if not all of it. However, as [Phil Karlton](http://karlton.hamilton.com/) says, [the only two hard things in programming are "naming things" and "cache invalidation"](http://www.tbray.org/ongoing/When/200x/2005/12/23/UPI). So the goal is to make the framework fast for dynamic requests, without relying on caching as a band-aid over poor architectural decisions.
Lithium is specifically architected to be fast and flexible, and PHP 5.3 helps with both of these goals. Lithium leverages features like namespaces, autoloading, late static binding, lambdas and closures, among the many smaller optimizations that are new in 5.3. With closures, Lithium provides an API to add filters to specific methods that the core exposes. This allows you to write code that only happens when you want it to and helps keep the core lean without hampering extensibility.
Going back to Paul's results, we know that Solar is fast and should be considered the baseline for framework benchmarks for a couple of reasons. First, Solar is well written with clean use of patterns and a focus on performance. Second, because Solar does not use any dynamic routing out of the box. After cache grinding in Lithium, it's clear that compiling routes is one of the slowest processes, and you will see that reflected in the results.
## My test platform
[Rackspace Cloud](http://www.rackspacecloud.com/cloud_hosting_products/servers/specifications)
- 256MB ram
- Ubuntu Karmic
- Apache 2.2.12
- PHP 5.3.1
- Xcache
- Siege 2.68
## Some code to make things run
_Solar Beta r4250_ uses a layout which needs to be disabled.
{{{
class Solar_App_Hello extends Solar_Controller_Page {
protected $_action_default = 'index';
public function actionIndex() {
$this->_layout = null;
}
}
}}}
_Lithium_ includes a HelloWorldController, so no modifications needed
_Lithium no routing_ replaces the code in switchboard.php with this:
{{{
use \lithium\action\Dispatcher;
Dispatcher::applyFilter('run', function($self, $params, $chain) {
$request = new \lithium\action\Request();
$request->params = array('controller' => 'hello_world', 'action' => 'index');
$callable = $self::invokeMethod('_callable', array($request, $request->params, array()));
return $self::invokeMethod('_call', array($callable, $request, $request->params));
});
}}}
The code above gives you a look into the filter system. Essentially, we replace the run method of dispatcher and build the request.
## Siege
```siege -b -c10 -t60 http://path/to/hello_world```
## Now, the numbers.
[graph generated with R by Joel Perras](http://rad-dev.org/lithium/wiki/tools/benchmarking)
From this graph we see that Solar is slightly faster even when routing is removed. So, we go back to xdebug profiling and we find out that the Lithium Libraries class could be optimized a bit. The Libraries class is extremely powerful and is used to add source to the Lithium chemistry. Libraries enables easy plugin and 3rd party inclusion. For example, checkout out this snippet to add Doctrine 2.
{{{
Libraries::add('doctrine', array(
'path' => LITHIUM_LIBRARY_PATH . '/doctrine/lib/Doctrine'
));
}}}
Doctrine 2 follows the same [PHP Interoperability Group Standard](http://groups.google.com/group/php-standards/web/psr-0-final-proposal), so we can make it simple.
To add Solar, we might do something like
{{{
Libraries::add('solar', array(
'prefix' => 'Solar_',
'path' => LITHIUM_LIBRARY_PATH . '/Solar'
'transform' => function($class, $params) {
return $params['path'] . str_replace('_', '/', $class);
}
));
}}}
Now any Solar or Doctrine class can be used within Lithium, with the classes being autoloaded for us, without needing to change the include path or mess with custom autoloaders.
As you can see, Lithium already seems to be both fast and flexible. Still, we can quickly add some optimizations like caching Libraries paths and Routes through the filter system. Additionally, there are probably several core routines we can optimize in the future. With test suite filters like profiling and cyclomatic complexity, we can measure the changes over time to ensure that Lithium remains fast and flexible.
Hopefully, this gives you a little glimpse into the chemistry that makes Lithium different and shows the efforts the team is making to produce a fast, flexible, and reliable framework. Please, stop by #li3 on irc.freenode.net if you have any comments.
Happy Thanksgiving.
~ gwoo
