Benchmark and profile the ServiceProvider

[halter73]

As part of PR #121, we made some changes to improve the performance of service resolution from ServiceProvider.

However, as of yet, we have not specifically benchmarked the performance of ServiceProvider. We should create some microbenchmarks for ServiceProvider so we can measure the performance impact of the changes we make to ServiceProvider and profile the ServiceProvider code. Microbenchmarks can be a useful tool even though they do not reflect real-world usage patterns.

@GrabYourPitchforks has suggested that it isn't necessary to use compiled expression trees to replace code that does not use reflection. If the performance impact is negligible, it might be better to use expression trees sparingly just for things like constructor invocation to make the code simpler and easier to debug. Once we have benchmarks, we can measure what the performance difference of compiling more or less. This should help us decide which approach we should take.

[matthewDDennis]

Back in 2010 I published an log post Introduction to Munq IOC Container for ASP.NET. As part of this article, I compared the performance of the current 'standard' DI Containers. Mine was the fastest, not surprisingly as that was its primary design goal.

However, I updated the tests the other night and added the ASPNET Core Dependency Injection package to the mix. I was pleasantly surprised to find that the ASPNET DIwas slightly faster than Munq, and has detection of cyclic dependencies, a feature that Munq does not have. The results are shown below;

Running 100000 iterations for each use case.
                          Test:        Ticks -         mSec -   Normalized
              No IOC Container:       34,835 -        14.30 -         1.00
                          Munq:      610,249 -       250.53 -        17.52
                   MunqGeneric:      556,710 -       228.55 -        15.98
                       Autofac:    2,137,324 -       877.44 -        61.36
                  StructureMap:    1,459,123 -       599.02 -        41.89
                      Ninject2:   32,251,813 -    13,240.37 -       925.85
                       Windsor:    6,666,628 -     2,736.86 -       191.38
                      AspNetDI:      268,442 -       110.20 -         7.71
    No IOC Container Singleton:        2,161 -         0.89 -         0.06
                 MunqSingleton:       67,732 -        27.81 -         1.94
              AutofacSingleton:      388,387 -       159.44 -        11.15
         StructureMapSingleton:      619,457 -       254.31 -        17.78
             Ninject2Singleton:    5,276,335 -     2,166.10 -       151.47
              WindsorSingleton:      125,913 -        51.69 -         3.61
     AspNetDISingletonUseCase :       34,082 -        13.99 -         0.98

You can find the source for the tests at https://github.com/matthewDDennis/Performance.

I don't think you have to worry about performance too much with this system. It is fast enough that rest of the application's code execution time will be orders of magnitude larger than the DI code.

You might also like to see the article Munq is for web, Unity is for Enterprise by Omar AL Zabir.

[seesharper]

You also might want to check out this benchmark.

https://github.com/danielpalme/IocPerformance

[Eilon]

Closing because we have already done other investigations in this space, so this bug isn't needed.