PHP Dependency Injection Container Performance Benchmarks

By Tom Butler

Working with PHP 7.1? Download our FREE PHP 7.1 Cheat Sheet!

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.

  • Maxime Fabre

    No love for Laravel’s ?

    • codeatbusiness

      +1 Laravel Dependency Injection management is great.

    • Feel free to correct this if I’m wrong but unfortunately Laravel does not provide an accessible standalone instance of its DI container, it looks like it’s heavily coupled to the framework stack as it uses static methods in the App class, which itself is somewhat problematic as it implies the use of global state

      • Laravel is built on top of Components, same as Symfony. The container is usable from here

      • Iqbal Ahmed

        Laravel app class doesn’t use static methods. It uses facade design pattern.

        • Tom Butler

          app::bind is a static method…. facade or not, it creates all the problems that any static method does. That said, I will use Laravel’s Container in the next round of benchmarks.

  • Stephan Hochdörfer

    Pimple can be configured to return new instances for every call. You simply need to wrap your anonymous function with the factory() method. See the documentation on “Defining Factory Services” how that is done.

    • That still requires pimple to be backed by a proper injector

      • Dionis Spinei

        What do you mean a proper injector and why would Pimple need that? By default Symfony DI container also returns the same instance.

  • Good to see aura doing well :) .

  • Not all of the containers tested are pure DI; I would argue this is actually a benchmark of IoC containers. As such, I’d love it if you would extend the benchmarks to add ZendServiceManager to this, as a) it is an IoC container, and b) far more widely used than ZendDi (we actually discourage use of Di due to its known performance issues, as well as the difficulty in consumption). This would give a better comparison for those using these benchmarks to compare frameworks.

  • Of course it can be taken out and used but there is no official documentation that I can see for using the container outside the framework stack. The framework documentation requires use of the framework to run the examples in the docs. For someone looking for a Dependency Injection Container to use in one of their projects it’s not going to matter how fast it is if there’s no examples of how to use it or even a list of features. ZendDi relies on several other framework libraries, but the example code can be run without the use of running the entire framework, which is a big difference.

    • Erik Wiesenthal

      Actually Laravel Container is as easy to use as Pimple. Both of them can be used to return new instances. I would like to see them added to the benchmarks.

      [quoted from pimple]
      By default, each time you get a service, Pimple returns the same instance of it. If you want a different instance to be returned for all calls, wrap your anonymous function with the factory() method

    • Ionut Bajescu

      You dont need a documentation for this. = 0 dependencies.

    • Jonathan Reinink

      FWIW, I use illuminate/container quite often in my non-Laravel projects, and I simply follow the documentation offered on the Laravel website ( You just need to instantiate the container yourself, instead of use the “App” facade. And as noted, this package has zero other dependencies.

  • .Jan Rybařík

    And what about Nette framework. Do you know that? :-)

  • I’ve added NetteDI to your benchmark, so you can see how kickass DI Containers work :)

  • lsmith77

    Symfony2 gives the option to compile and cache the container which is what Symfony2 fullstack does by default to provide some high level features and improve performance:

  • stanlemon

    Another DI benchmark without using Symfony’s container compiler… Seems to it a disservice IMO.

  • papayasoft

    Re: composer: The repository for the tests does not do need to contain all the libraries under test. You can point `composer.json` to the specific versions – whether by tag or even by specific SHA1 revision – of the dependencies to get the precise versions you want. This would maintain the same determinism in the test suite, while increasing flexibility to repeat the tests on different versions.

    • Seer

      Yeah, not sure why this isn’t being done. It just makes the repository a bit of a mess currently.

  • Such a great article, well done. I’ll wait for the update version that will include pimple, nette and laravel!

    I also discovered you are the author of Dice, so well done again!

  • happyaccidents

    I’d be interested to know what was considered limited about OrnoDi compared to the other containers?

    • I’m planning to do another article that contains a feature comparison but PHP-DI, Dice and Zend all have features that OrnoDi does not, such as a lot more control over automatic injection.

      • If you need any info about Nette for the next article, just ping me, I can provide any info you may need :)

      • happyaccidents

        I may be a little biased but I wouldn’t say OrnoDi is limited in functionality compared to the other containers at all, your use case may not be documented, but I’d be happy for you to ping me an email when you’re comparing features so I can explain how to implement anything you need to do.

        • To anyone looking for a Dependency Injection Container to use in their project, an undocumented feature is identical to a non-existent feature.

          For me doing a feature comparison with a goal of helping people make a choice on which container to use, I can only go by documented features.

          • happyaccidents

            Why do all comments from you (past and present) always seem so defensive? I’m simply asking for an example of when you found it “limited” so if it makes sense, then it can be implemented, and if the functionality is there I can point that out to you.

            “an undocumented feature is identical to a non-existent feature” this is simply untrue, there are intended use cases and unintended use cases, this doesn’t mean the feature isn’t there. For example, I would guess that none of these containers document that they can be used as service locators, does that mean that they cannot be used in that way?

          • You chop off the important part of that quote then purposefully take it out of context, then ask me why I’m defensive? Of course the part you quoted is untrue but you missed out the preface: “to anyone looking for”. It’s disingenuous to imply new users who are choosing between two or more libraries that perform the same task would look through the code line by line to see what it may or may not be capable of.

          • happyaccidents

            Well your sentence is still untrue regardless of the preface existing or not.

            Control over something automatic would suggest that it is no longer automatic, therefore that is not really an example, I am asking for a specific example so I can either document it’s use, implement it if it makes sense or point out why it’s not implemented, but a vague comment like that gives me nothing to go on at all.

  • Jakub Kulhan

    Nobody uses (or at least should not use) runtime object graph resolution in production. What you really want to use is Symfony’s compiled container (as suggested in PR, or NetteDI container (or any other container that compiles into PHP code in production).

  • WooDzu

    Great work! Personally I’d like to see how PhalconDi stands among others.

    • Alex Hoang

      I know who you are :))

  • I’ve looked at what the compiler does and it seems to convert every definition into a factory method. If that’s correct then the SymfonyDi would have to be compared only with factory based definitions on the other DIs.

  • liquorvicar

    Probably worth point out at the top of the article that you are the maintainer of Dice, is it not? Not suggesting you have anything but good intentions but for the sake of complete transparency…

  • You didn’t use any kind of cache for PHP-DI :(

    I’ll work on a PR asap, but it seems you also didn’t compile Symfony’s container. I’ve been trying to make such a benchmark for a long time, it’s very complicated. It’s usually better when you finished to ask for review from library authors.

    Edit: I did the PR. I’ve seen a 2× speed improvement on all tests, and much more on test 3.

    As I said in the issue, I think measuring the number of required files is useless since the only real metrics are “speed” and “memory usage”. Any other metric is just affecting those ones. Be sure to also run the tests with an opcode cache, which can make a difference for containers requiring many files.


    I haven’t examined your tests on github in details, but on first glance, I only see cases for testing behavior of service locator implementations. So I agree with @weierophinney:disqus’s observation.

    • nnn

      Maybe you can show where exactly you see it (service locator implementation) ?

  • Alex Stansfield

    Regarding pimple. Version 1.x returns new instances of services by default.

    Whilst 1.x is not the latest version it is the version that the stable versions of the micro frameworks silex and cilex are built on and might make it worth including.

  • Iqbal: that’s a common misconception among Laravel folk. The term “facade” is used improperly there; the pattern on display is more like a static proxy to a service locator instance. The fact that you (and others!) continue to be led astray by the poor choice of name in Laravel (i.e., calling something a “facade” that is not in fact a facade) underlines the points I have been making about how important it is to use the correct names for things.

    • AmyStephen

      It’s also a matter of opinion, Paul, since it is, indeed, a Facade. In the big picture of things it seems mostly to matter to providers of frameworks other than Laravel, not the devs who use Laravel.

  • Larry Garfield

    “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.”

    I’m sorry, what?

    No, actually, I’m not sorry. That is a horribly misleading and incorrect statement. The difference between a DIC and an SL is the usage pattern. Whether it returns the same instance or reuses it on subsequent requests is completely irrelevant.

    Well, no, that’s not true either. Why would you want a new instance of the object on every request? Really, when? If I’m passing a DB connection or Redis connection object or anything containing a resource reference via DI, you better believe I want the object reused. I don’t even know what the use case is to not do so, frankly.

    Also, as others have noted Piimple is completely capable of making a new object on each request or reusing it on each request. The default switched in Pimple 2 but both are still possible. Both are also completely possible in Symfony’s DI component, too. Yet you said one is a DIC and the other isn’t?

    Also, as others have noted you forgot to use compilation on several of the containers, which automatically puts them at a disadvantage. That’s equivalent to comparing two frameworks but running one on PHP 5.2 with no opcode cache and the other on PHP 5.5 (with built-in opcode cache, plus tons of engine improvements). The resulting comparison is completely meaningless.

    All in all this is a horribly misleading article with a faulty premise and faulty testing methods. I expect better from SitePoint.

    • “Well, no, that’s not true either. Why would you want a new instance of the object on every request? Really, when? If I’m passing a DB connection or Redis connection object or anything containing a resource reference via DI, you better believe I want the object reused. I don’t even know what the use case is to not do so, frankly.”

      Any object which isn’t a service needs to be a new instance on each request to the container, it makes no sense otherwise. Consider an MVC model/controller/view you may want two instances of these on a single page displaying different information, it breaks desired behaviour if the container returns the same instance on every request. In a real world application, the container will only return the same instance for objects which, as you say, are resources or shared services. This tends to be a small % of the total objects that exist within the application. If you are using the DIC as a Service Locator and manually fetching the services you want then it makes sense that you would only ever use the container to store reusable services, but that’s not what I’m testing here.

      I am doing a second set of benchmarks which address the issues you pointed out, and including Pimple and some of the other containers people suggested.

      • Larry Garfield

        We must be working on extremely different types of systems then. I’m one of the lead developers on Drupal 8. We have a huge number of objects registered in the Symfony Container we’re using. I don’t think more than one or two are “prototype” services (ie, re-created on each request rather than reused). The overwhelming majority of them are not taking the container as a parameter; they’re proper Dependency Injected services. A few are, for various reasons (some good, some bad). In that case we’re using the DIC as a service locator.

        You’re conflating “passing the container into an object so that it can pull in services” with “services are reused rather than repeatedly recreated”. Those are two entirely different attributes of a problem space/solution. There’s situations in which all combinations of those may be appropriate to do (and any good DIC can support all such combinations), but don’t conflate the two.

        • I never suggested passing the container into anything. The reason a lot of web frameworks get away with treating a high proportion of objects as shared services is simply that the container (and the objects its managing) has to be recreated on every request. In any other programming language you’d realise that essentially creates global state because anything using the container gets a shared instance, the fact that a lot of objects are only used once per request lets you get away with treating them as shared services when they’re not, any object you’re only using once per request (Which is all the framework entry point stuff, all of the application’s controllers and views which you’re using once per page) should only be created as single instances. On the web you get away with treating them as shared objects but it’s a cludge.

          • > object you’re only using once per request (Which is all the framework entry point stuff, all of the application’s controllers and views which you’re using once per page) should only be created as single instances.

            Preach the Word! The whole “controllers as services” thing never sat well with me and that’s a good description of why.

      • Jeff M

        I truly hope you take this as constructive criticism, Tom. It seems like you often end up in “The whole world is crazy; I’m the only sane one” kind of situations, where you tend to think that everyone else has got it wrong and you alone know the correct answer. This latest example is that everyone else thinks Pimple is a DIC, but you alone know it’s not. And, like Larry, your explanation makes me wonder whether you actually understand DICs. Whether a factory method returns a new instance or a shared instance has nothing — at all — to do with whether it’s DI or SL. When you find yourself again in a similar situation of thinking that the whole world got it wrong, I strongly strongly suggest that you talk to lots of people and reconsider your conclusion, because it’s tremendously more likely that the world got it right and it’s just you who missed some crucial detail. These days, some of the smartest people in the field are easily accessible through Twitter or Reddit or whatever.

  • Ray.Di looks interesting but it’s annotation based which is a DI antipattern, and secondly, the version on github doesn’t work, it fails with Fatal error: Call to undefined method RayAopMatcher::setAnnotationReader() when trying to run the example code.

    • I have asked the creator to ping here. He will have a look into the issue and address it .

      Thank you.

    • Richard McIntyre

      I see from your blog that you have a small amount of a dislike for annotations. They are a mature part of many languages now. I don’t see why they should be considered specifically a ‘DI anti-pattern’. 2 of the most famous DI frameworks (Spring and Guice) indeed make use of them.

      Fair point about the sample code not working though…

      • The fact that other frameworks use annotations is no advocacy of their efficacy (argumentum ad populum), the use singletons and global state is also very common.

        With annotations, the developer of a given class is aware of the container and has to think about it when writing the class, this breaks encapsulation. More importantly, the annotation becomes part of the class API. Using annotations is no different than saying “To use this di framework, you must write your class with the method public function setDependencies(array $dependencies);”.

        • Richard McIntyre

          I will definitely chew over your points – you are thinking about things which is good. I like this over the `Annotations on services that configure DIC in java frameworks simply violate IoC.` comments which just sound like blanket statements. As for the annotations in Ray.DI you are not saying WHAT you are injecting – just marking it as an injection point. There is no `container`. You are right in your opinion of this where Spring is concerned but Guice/Ray.Di is different in this regard.

          • The developer still has to consider the DI Container when writing their class and include the annotations. The class then becomes targetted at a specific DIC. If you wanted to use the class in a different project with a different container that also used annotations you would have open up the class and rewrite each annotation. This causes problems with portability and version control (if you fix a bug in the original class, you can’t just push it to the other project because the class had to be changed to work in the other project)

            I wrote a blog post on this topic here:

      • Annotations on services that configure DIC in java frameworks simply violate IoC.

  • Larry Garfield

    I never said there was perfect code. There’s always exceptions to best practices that have to be made. But you should at least call them what they are, honestly. Passing a whole container into an object and calling it a “Factory” is, er, wrong. It may be an appropriate thing to do or not, depending on the circumstances, but calling it a factory is still wrong.

    • AmyStephen

      I think you mean calling it a “Facade?” See how easy it is to use the wrong term?

      You are making my point. When leading PHP devs make such strong stands on nomenclature, it has a negative impact on acceptance but it does nothing to help developers use better approaches.

      What we should do is share the link to Taylor’s post which shows how to avoid the practice entirely. That actually helps people use Laraval in a better way and avoids the whole Facade -vs- Proxy -vs- Factory silliness.

      • Larry Garfield

        No, I used the term Factory very specifically and deliberately to be an example different from the one in Laravel. There was no mistake.

        • AmyStephen

          OK, but I fear Larry we’ve kind of wandered off topic, then.

          Laravel devs read Taylor’s post
 – no statics, no
          injected factory, no injected container — it’s DI via constructor at
          it’s finest. =)

          • Amy, I think it is you who has wandered. That link does not address the improper use of the word Facade.

          • AmyStephen

            Right, I know Paul, but that little labeling argument is your crusade, not mine.

            What I think is helpful is to encourage developers to do is use Dependency Injection via the Constructor rather than passing static instances around in an application. I’m quite certain you agree.

            So, towards that end, I like to encourage developers to follow Taylor’s advice here

            It really should make you happy, too, since the entire question about Facades is set aside and we can all feel good about improved PHP code.

  • Note the beginning of this particular thread originates in my accurate observation that Laravel uses the term Facade improperly.

    The “little labeling argument” is the subject here, not statics or DI. So, to reiterate, it is *you* who has drifted off to other topics.

  • ‘”The whole world is crazy; I’m the only sane one” kind of situations.’ That’s a little disingenuous. I have had multiple arguments with PHP Developers, but my own thoughts are in line with well known programmers and academics outside the PHP Community, it’s generally that PHP Developers do things differently (And yes, often wrongly) that misses the point of how/why something is done. Part of this, like Larry’s example is because PHP lets you get away with doing things you couldn’t in other languages without severe consequences, it doesn’t make it right/wrong but I tend to stand on the side of general programmers, rather than loooking through the very narrow PHP perspective.

    As for pimple it was pointed out that you can use it to construct new objects and I will be using it in the next set of benchmarks. However, something that can only ever one instance of a class cannot be considered a DIC because it can’t be used as such in a real world application

  • Chris Seufert

    Maybe I’m missing something here, but would you now have to put the Dice instance into a global, to reuse it inside other componenets?.


    During site start up, you call $dice->create(‘MyApplication’)->run(); all good, works as expected. however my application want to open a new Document that uses the database, currently i call $doc = Document::open($id); and i have a instance of my document, via something like this

    static function open($id) {
    $doc = $dice->create(‘Document’);
    $doc->data = $doc->db->selectAsArray(‘SELECT * FROM doc WHERE id=’$id’);
    return $doc;

    All looks to work well, but how did i get an instance of dice here in my application?

    If i create a new instance before doing this, then perhaps you should be putting the new Dice() inside your benchmark loop.

    • That’s not how DI works. Static methods are intrinsically anti-oop anyway but instead you should do something like this:

      Instead of calling Doc::open(123) you should pass in the fully constructed doc into whatever requires it:

      new Whatever(new Doc(123));

      Look up ‘inversion of control’ for a lot of examples as well as discussions about pros/cons of this approach.

  • What about Lavarel perfomance, Tom? :)

  • Eric

    You are the author of Dic and as if by chance it is strangely Dependency Injection is the lightest.
    concepte the design of the pattern php dependency injection container was
    conceptualized by Fabien Potencier at the base (creator Symfony2 no less ) .
    But I am amazed at your results. It reminds me of NotOrm library
    helping to facilitate the sql queries but have no need to go through
    a Orm ( doctirne propel gold ) that show much faster performance compared
    to doctrine but in the end was revealed to the slowest on high peak loads .

  • Rob Mall

    Looks just what I’m after, though am not sure how the use of Reflection will perform when scaled up. Do you have any metrics, especially from cold start ?

  • JJ

    How about auryn? this is probably the main ‘competitor’ to Dice… why did you skip it? I wonder how auryn compares to dice …. ?

Get the latest in PHP, once a week, for free.