[PSR-11] Issue 1-B - Running multiple containers side-by-side and the

[David Négrier]

Hi list,

As previously planned, I'm opening today a new topic regarding PSR-11: the possibility of having more than one container running in an application, and the performance impact of it.

One of PSR-11's key point is allowing 2 PHP dependency injection containers to work side-by-side (and to share entries). This is done through a mechanism called « delegate dependency lookup ». The whole mechanism is detailed in the META document. During the acceptance vote of PSR-11, I encountered quite a lot of criticism regarding the idea of having 2 or more containers side-by-side. Most comments were in one of those 2 categories:

- You should not do this because [insert philosophical reason here]
- You should not do this because it will bad for performances

Regarding philosophical comment you might have, I will just say this: a composite container is wrapping many containers. The application needs to know only about one container: the composite container. Therefore, there is really only one container that is used by the application.

Now, regarding performance: I do care a lot about performance. The comment about performance makes sense. If the composite container must test if an entry is available in many containers instead of one, there has to be a performance impact. The question is: is it big enough to be noticeable? So I decided to run a test to see if I could detect any impact on performances from an application with multiple containers.

For this test, I decided to work on a Symfony 2 application. My idea was to test the default « demo » page that comes with Symfony when you install the framework (the one described in the Quick tour document). I decided to test this page because it is quite close to a "real world use case", and it is not something that I could have modified to make the benchmark yield better results.

I modified Symfony 2 to make it PSR-11 compatible. This was surprisingly simple to do, even for a complex compiled container like Symfony.

Then I added a composite container, and many other PSR-11 compatible containers. I used Blackfire to test the difference.

The result? I was unable to measure any meaningful impact of running 21 containers together in Symfony demo page.

I wrote the details into a blog post that can be found here: http://www.thecodingmachine.com/psr-11-performance-impact-of-the-delegate-lookup-feature/

Both repositories used for this test are public on Github so that anyone can reproduce the tests.

I'm open to any suggestion or comment that would help improve these tests. Unless anyone objects or wants to run further tests, I would be willing to close this "performance" issue and move to the next topic.

Best regards,

David Négrier
http://mouf-php.com
Github: moufmouf
Twitter: @david_negrier

[Dracony]

 The application needs to know only about one container: the composite container. Therefore, there is really only one container that is used by the application.

 

I can't agree with this statement at all. When I absolutely must use containers as opposed to factories I still tend to structure them in a namespaced fashion. Each part of the application gets its own isolated container that contains only the things it is allowed to touch, for example the container that is passed around orm related stuff cannot be used from the classes that are responsible for command line stuff and so on. Although I allow top level containers to access nested containers with some delimeter ('stuff.database.someting'). Personally I feel that nesting containers with mandatory namespacing solves the performance problem entirely ( since there is only a single path to each target).

Merging multiple containers into one is imho a huge pain to debug later on (while I see the usability benefit of it).

[Attila Szeremi]

Dracony: what you are talking about is something different. I think what the others are talking about is that if you have a composite container structure using a delagate, then it should only be the delagate that you should be passing around in your code from then on.
In your example you are talking about separate containers from the main structure, and in that case it is those separate smaller containers that are their own separate individual structures (and being their own delagates at the same time too)

[Dracony]

Yes, its a different thing. But what I'm saying is that container composition with delagation is not a very common use case.

Actually such a composition is just one implementation detail. And since the PSR is just defining the interface its not really an issue.

On Wednesday, September 9, 2015 at 6:35:09 PM UTC+2, David Négrier wrote: