By Tom Butler

PHP Dependency Injection Container Performance Benchmarks

By Tom Butler
Last chance to win! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min

Most frameworks and larger PHP applications utilize a Dependency Injection Container with the goal of a more maintainable codebase. However, this can have an impact on performance. As loading times matter, keeping sites fast is important as ever. Today I’m going to benchmark several PHP Dependency Injection containers to see what their relative performance is like.

For those unfamiliar with the concept, a Dependency Injection Container is a piece of software which automatically builds an object tree. For example, consider a User object which requires a Database instance.

$user = new User(new Database());

A Dependency Injection Container can be used to automatically construct the object tree without needing to provide the parameters manually:


$user = $container->get('User');

Each time this is called, a user object will be created with the database object “injected”.

There are several well known (and not so well known) containers available for PHP:

  • PHP-DI, a popular DI Container
  • Symfony\DependencyInjection, the the Dependency Injection Container provided by the Symfony framework
  • Zend\Di the Dependency Injection Container provided by Zend Framework
  • Orno\Di, a lesser known container with limited features but developed with performance in mind
  • Dice, another lesser known container with a focus on being lightweight. Full disclosure, I’m the author of this container, but I’ll be nothing short of entirely objective in this analysis.
  • Aura.Di, a fairly popular container with minimal features

A word on Pimple: Although Pimple is advertised as a Dependency Injection Container, retrieving an object from the container always returns the same instance, which makes Pimple a Service Locator rather than a Dependency Injection Container and as such, cannot be tested.

Although all the containers support different features, this benchmark will cover the basic functionality required by a Dependency Injection Container. That is, creating objects and injecting dependencies where they’re needed.

Which aspects of dependency injection will be measured?

  1. Execution time
  2. Memory Usage
  3. Number of files included. Although this has very little impact on performance it’s a good indicator of how lightweight and portable a library is. If you have to ship hundreds files with your project because of your DI choice, it can heavily impact the overall weight of your own application.

Testing environment

All tests were run on the same machine running Arch Linux (3.15 Kernel), PHP 5.5.13 and the latest versions of each container as of 03/07/2014.

All execution time numbers presented are an average of 10 runs after discarding any that are over 20% slower than the fastest.

Test 1 – Create an instance of an object

This test uses each container to create a simple object 10,000 times

Without a Dependency Injection Container, this would be written as:

for ($i = 0; $i < 10000; $i++) {
      $a = new A;

Test code (on github): Aura, Dice, Orno\Di, PHP-DI, Symfony\DependencyInjection, Zend\Di

Test 1 - Execution Time

As you can see, there’s two clear camps here. Aura, Dice and Orno being roughly ten times faster than PHP-DI, Symfony and Zend\DI.

Test 1 - Memory Usage

Similar to Execution Time, there are two distinct groups with Symfony sitting somewhere in the middle ground.

Test 1 - Number of Files

This is very telling of how lightweight each container is and goes some way towards explaining the memory usage differences. It should be noted that a lot of the files used by Zend\Di are common framework files so if you’re using Zend Framework, then using Zend\Di will not incur the same memory overhead as files will likely be reused elsewhere in your application.

Similarly, PHP-DI heavily relies on Doctrine libraries. If you’re using Doctrine in your project, then the memory overhead of PHP-DI is reduced.

However, It’s nice to see that Symfony\DependencyInjection, despite being part of the framework stack is entirely standalone and works without any dependencies from other Symfony projects.

Aura, Dice and Orno do not have any external dependencies and this helps keep their file counts down.

Test 2 – Ignoring autoloading

As loading files can impact performance and both Zend and PHP-DI loaded a significant number of files, the same test was conducted ignoring the autoloader time by first creating a single instance of the class, ensuring any required classes were autoloaded before measuring the time.

This may also have triggered any internal caching done by the container but the same treatment was applied to each container to keep it fair

Equivalent PHP code:

for ($i = 0; $i < 10000; $i++) {
          $a = new A;

Test code (on github): Aura, Dice, Orno\Di, PHP-DI, Symfony\DependencyInjection, Zend\Di

Test 2 - Execution Time

Test 2 - Execution Time

Test 2 - Execution Time

As expected, memory usage is unchanged and performance is slightly better as the autoloader time isn’t being measured. However, this shows that PHP-DI, even loading 42 files has a negligible impact on the total execution time and the relative performance remains the same, loading dozens of files is not the cause of PHP-DI and Zend\DI having relatively slow performance.

Even after ignoring the overhead of loading files, there are still two distinct ballparks here. Aura, Dice and Orno are very similar in performance and memory usage while PHP-DI, Zend and Symfony are only in competition with each other.

All the tests going forward will ignore the autoloading time to ensure it’s truly the container’s performance that is being measured.

Test 3 – Deep object graph

This test is done by having the containers construct this set of objects 10,000 times:

for ($i = 0; $i < 10000; $i++) {
        $j = new J(new I(new H(new G(new F(new E(new D(new C(new B(new A())))))))));

Test code (on github): Aura, Dice, Orno\Di, PHP-DI, Symfony\DependencyInjection, Zend\Di

Note: As you can see by looking at the test code, Symfony, PHP-DI and Aura require considerably more configuration code than the other containers to perform this test. The configuration time was not included in the test.

Test 3 - Execution Time

Again, there’s very little difference between the top 3, with Dice 20% faster than Aura and 70% faster than Orno. All three are considerably faster than Zend, PHP-DI and Symfony. The difference between the three top containers is so slight in real terms that you would never notice the speed difference outside an artificial benchmark like this.

Zend, PHP-DI and to a lesser extent Symfony are slow here. Zend takes 37 seconds to perform a task Dice manages in under 1 second; certainly not a trivial difference. Yet again, Symfony takes the lead among the big name containers.

Test 3 - Memory Usage

Test 3 - Memory Usage

Memory and file counts are consistent with what we’ve seen in other tests.

Test 4 – Fetching a Service from the container

DI Containers also have to store and retrieve services which will be reused throughout the application. This test fetches a single instance from the container repeatedly.

Pure PHP Equivalent:

$a = new A;
    for ($i = 0; $i < 10000; $i++) {
      $a1 = $a;

Test code (on github): Aura, Dice, Orno\Di, PHP-DI, Symfony\DependencyInjection, Zend\Di

Test 4 - Execution Time

This is unexpected based on previous results. All the containers except Zend and Symfony are roughly equal with just 0.01s separating the top 4 results. Symfony is not far behind, but Zend is well over ten times slower than the others.

Test 4 - Memory Usage

Test 4 - Number of Files

Memory usage and number of files results are becoming predictable with the same division between the containers that we’ve seen in execution time throughout.

Test 5 – Inject a service

The final test is to see how quickly an object can be constructed and have a service injected. This takes the format:

$a = new A;
    for ($i = 0; $i < 10000; $i++) {
        $b = new B($a);

Test code (on github): Aura, Dice, Orno\Di, PHP-DI, Symfony\DependencyInjection, Zend\Di

Test 5 - Execution Time

Interestingly, Aura has taken a slight lead in this test. However, it’s not quite a like-for-like test as Symfony and Aura require several lines of explicit configuration while the other containers automatically resolve the dependency. The time taken to configure the container was not part of the benchmark.

Surprisingly, PHP-DI is the slowest at this task, with Zend taking its position ahead of PHP-DI and Symfony for the first time.

Test 5 - Memory Usage

Test 5 - Number of Files


On performance alone, Dice, Aura and Orno are all strong competitors, Dice is fastest overall and Aura fastest in the final test. The difference between the two distinct groups is apparent but its interesting to compare features of each container. Number of features and performance do not quite correlate as you’d expect. Both PHP-DI and Dice contain unique features but PHP-DI takes a heavy performance hit for doing so. Aura, although fast, requires a lot of manual configuration and does, as you’d expect, have very minimal features whereas Dice and Orno have very similar performance but require a lot less code to configure.

Symfony is very much in the middle ground in all tests, although configuring it, as with Aura, is a much more difficult task as neither support type hinted parameters. If you’re looking for a container from a well known project, then Symfony has to be the container of choice if performance is important.

That said, if pure performance is what you’re after then Dice and Aura are the clear winners with Orno very close behind. However, it’s worth taking a look at configuration syntax and features of each to see which you would prefer working with as the performance difference between Dice, Aura and Orno is negligible for any real application.

All the code for the tests is available on github. Please note: The github repository contains copies of the libraries tested rather than using composer to include them in the project, this is to ensure that you can run the code with the exact versions I tested and get the same results.

Login or Create Account to Comment
Login Create Account
Get the most important and interesting stories in tech. Straight to your inbox, daily.
Is it good?Is it good?