Performance Impact of Using Spring.NET Dependency Injection

August 10, 2009
By Chris Bennett

Send Email »
More Articles »

This application performs 4 tests. The first two tests are the same as those performed in the native .NET application above, but performed using Spring.NET. The last two tests test the performance of using varying levels of injection. Test #3 creates a ConcreteCalculate object each time, but uses Simple and Complex math singletons. Test #4 uses ConcreteCalculate, Simple and Complex math singletons. After running this application you should see similar results to the image below:

Figure 2 - Testing Spring.NET Application Results

Review the Results

To make the review simpler, I've created the following table to pull in the results from the two test applications.

Test	Native .Net	Spring.Net
Test #1: Create Objects	15.625ms	7015.625ms
Test #2: Use Single Object	15.625ms	15.625ms
Test #3: Pass Singletons	N/A	3890.625ms
Test #4: Use All Singletons	N/A	156.25ms

The import test to take note of is Test #1 where both applications created an object 100,000 times. For Spring.NET this is obviously a very expensive operation compared to native .NET code. Test #2 confirms that after the object is created the performance is the same with or without Spring.NET. Test #3 and #4 illustrate that Spring.NET performs better when it is able to reuse objects. Still while reusing objects, the performance is significantly more time consuming than native .NET code.

Conclusion

Spring.NET certainly provides flexibility, however, the flexibility comes at a performance price. For many applications the performance impact is minimal. If your application creates most or all of it's objects upon startup, then the only cost is slower application startup. On the other hand, if you need to create objects very rapidly and performance is a concern, then you probably should use another framework or minimize the use of dynamic injection. It is also important to note that as of the time of this writing, Spring.NET is in version 1.2. Future versions of the framework may have improved the performance for creating objects. The intent of this article is not to try to turn people away from using Spring.NET. However, when using Spring.NET we need to be aware of the performance cost for the added flexibility.

Download the source code by clicking here.