v7 resolution plan caching and container hierarchy

[DenSpirit]

Hello and thank you for working on the project. I've been a long-time user of Inversify v6, and I have developed a method of work that improved code readability significantly.

In the web server projects I use Inversify in, there are a couple services defined that have normal dependencies between each other. Some services however depend on request information, and it was quite useful to inject it by using a child container. The services and derived values were defined in parent (root) container, and then I created a one-off child container for every request, populating values from request there. Then all services would be resolved using the child container.

I was not concerned about efficiency, since I thought the containers were glorified hashmaps that delegate to parent when they cannot find something. Maybe this was true for v6, but after seeing the cacheable request plans blog in v7 I decided to take a look how much it changed, and I see there is a lot going on.

In particular, after reading the code I can see that plan caching service object is instantiated for every child container, and it's then subscribed to parent's plan caching service. It could mean that the "one-off child" method for requests is going to be way less efficient, denying caching benefits.

Is it possible that a better method of work exists that I don't know about? Or maybe I misunderstood the workings of plan caching and it will work for me, or I should start with profiling if the effect is significant enough...

Any suggestions are welcome!

[notaphplover]

Hey @DenSpirit, you probably don't need to worry too much about performance in your case if you don't see a noticeable overhead in the server.

In particular, after reading the code I can see that plan caching service object is instantiated for every child container, and it's then subscribed to parent's plan caching service. It could mean that the "one-off child" method for requests is going to be way less efficient, denying caching benefits.

Yeah, that's right. Propagating request related values in a RequestContext param could be a way to avoid this. The main issue I see is you're probably creating lots of objects in each request. As said, maybe this is not an issue at all if it's not causing a bottleneck.

Is it possible that a better method of work exists that I don't know about? Or maybe I misunderstood the workings of plan caching and it will work for me, or I should start with profiling if the effect is significant enough...

Better or worse depends on what are our goals. If we are only focusing on minimizing the overhead added by the library, stateless http servers often play very well with singleton scoped services, which are the best way to minimize the overhead.