Performance problems from dependency injection

Question

In my profiler reports I'm increasingly seeing the results of mock-based testing with dependency injection. Many of the dependencies were static, but because we want to test methods in isolation they are changed to instance members, like the following example:

class ShortLivedThing {
   IDependency1 dep1;
   IDependency1 dep2;
   IDependency1 dep3;
   ...

   int TheRealData;

   // Constructor used in production 
   public ShortLivedThing() {
     dep1 = new Dep1(); dep2 = new Dep2(); dep3 = new Dep3();
   }

   // DI for testing 
   public ShortLivedThing(IDependency1 d1, IDependency2 d2, IDependency3 d3) { 
     dep1 = d1(); dep2 = d2(); dep3 = d3();
   }
}

In turn the dependencies most of the time have other dependencies and so on. This results in the instantiation of a tree of (mostly "static") objects every time a method call is done outside of tests. Each of the objects are very small (just a few pointers), but the tree effect turns this into an ever increasing performance hit.

What can we do about it?

Answer 1

It seems to me like you need to leverage the features a proper dependency injection framework can give you. Do not use different construction logic for testing/production.

With spring, singleton injections are only performed at container startup. Prototype injections are done every time. The full wiring is also done each time you run a unit test, if it's being wired. So profiling unit tests is generally not a good idea.

Maybe you're using too little of the singleton scopes and too much prototype scope ? (Prototype = new instance every time)

The nice thing about spring injection is that you can use scope proxies, meaning your object graph can look like this:

 A Singleton
 |
 B Singleton
 |
 C Prototype (per-invocation)
 |
 D Singleton
 |
 E Session scope (web app)
 |
 F Singleton

And each request would only create 1 instance of C and one instance of E per session. A, B, D and F are singletons. If it's not a webapp you dont have session scope by default, but you can also make custom scopes (a "Window" scope sounds cool for a windowed desktop app). The clue here is that you can "introduce" scopes at any level, effectively you can have ten layers of singleton objects and all of a sudden something session scoped shows up. (This can really revolutionize how you implement some cross-cutting features in a layered architecture but that's a different story)

This really gives the minimum object creation possible within a DI model, I think.

Although this is Spring for Java I believe a number of other DI frameworks should support similar features. Maybe not the most minimalistic ones.