Since v2 it is no longer true.
Here is the extensive list of topics covered https://bitbucket.org/dadhi/dryioc/wiki/Home#markdown-header-usage-guide

Regarding supported platforms, almost everything is supported, including .NET Core. In addition support still starts from .NET 3.5, which is mostly abondoned by the rest of the folks.

I would like to contribute by creating an web app to display the test result nicely.
The results could be sorted, hidden, or graphed.
The app will be scheduled to run every times a new version of IoC is updated.
The app will be hosted on Azure App Service.

Are you interested in PR for this feature?

See http://www.lightinject.net

Hi Daniel.

I think you should not start and stop the StopWatch inside the tight loop.

There is a pretty large overhead associated with starting and stopping so frequently and it could affect the performance numbers.

Se this for reference

http://stackoverflow.com/questions/4088768/stopwatch-weird-behavior

Best regards

Bernhard Richter

I just tried to comile with vs2019 and got the following error

Fody: PEVerify of the assembly failed.
[IL]: Error: [C:\dev\GitHub\IocPerformance\IocPerformance\bin\Debug\IocPerformance.exe : DryIocZero.Request::ToString][offset 0x0000002B] Cannot change initonly field outside its .ctor.(Error: 0x80131884)

seems to be related to your code @dadhi, can you have a look?

First, thank you very much for your work!

Would be very interesting to add Microsoft.Extensions.Hosting and see the results.
See https://montemagno.com/add-asp-net-cores-dependency-injection-into-xamarin-apps-with-hostbuilder/

With the changes introduced with issue #71 we attempted to level the playing field and come up with a more real world test. This give a speed advantage to containers that have less features.

This wasn't a concern before as the top containers all competed in all the benchmarks (minus the child container). Now that abioc is the top container it competes in less than half the benchmarks and has a real advantage.

My suggestion is to add a method for each adapter that is called at the end of warm up to resolve some dummy services to level the play field.

So for example Stashbox, Grace and Autofac would resolve 0 dummy registration as they compete in all, LightInject, DryIoC would resolve 3 dummy registration, abioc would resolve 18 (6 benchmarks x 3) and so forth.

suggest add Api Friendly evaluate,

For example, DryIoc, its API is very unfriendly and inconvenient to use.

The problem is that the number of root services (services resolved directly from the container) grow gradually as the various benchmarks are executed. Most containers have some kind of dictionary that maps a service type to the delegate that represents resolving the service. When we talk about the top performing containers, looking up this delegate is actually what sets them apart. Some use a simple dictionary while others use a more optimized structure such as a binary search tree.

The first test is Singleton and after warmup we will have 3 root services, ISingleton1, ISingleton2 and ISingleton3. For the next test which is Transient we will have 6 root services, ITransient1, ITransient2 and ITransient3 in addition to the 3 services from the singleton test.

This means that service lookop will gradually cost more and more as the runner loops through the tests.

When the test runner reaches the last test the container will have root services for all services retrieved through the IContainerAdapter.Resolve method. Sort of a before all warmup.

I think the best solution would be to run all the benchmarks at startup so that all root services has been resolved once before starting the main run.

This also makes for a more real-life scenario as it is not unusual to have quite a few root services in a container.

I have noticed a rather big sudden performance regression for Singularity in this benchmark which I cannot reproduce (by checking out this repo and running the benchmarks) and also iam not aware of any changes made to the code that might have caused this.

Just speculating here but was the benchmark accidentally run in debug mode?

Please update UnityContainer to the latest version

Please add Lamar. Thanks

Currently the aspnet core benchmark resolves just a single scoped instances 3 times per scope. This makes it very easy to design a container that scores high on this specific workload. All one needs to do is use a datastructure thats fast on adding items and fast on returning that item if there is only 1 item. A datastructure such as a singlylinked list or even a simple field could be used for this.

Containers using such a datastructure in this case may seem to be the fastest however given the fact that such a approach does not scale very well it may give the wrong impression.

Just to give you a idea its pretty trivial to make Singularity perform 2x faster on this benchmark by doing this.

I think it would be better if:

• More work is done per scope. Currently there is lots of overhead in creating the scope itself because the actual workload inside the scope itself is very small.
• There are more than 1 scoped instances. This should make it harder to cheese the benchmark with a SinglyLinked list or even a simple field to store the scoped instance.
• These scoped instances are resolved many times to put more pressure on the read performance of the particular datastructure that a given container is using. If this is not changed then the benchmark would favor datastructures that are fast on adding new items.

There doesn't seem to be a benchmark for the asp.net core DI that comes out of the box. Would be really to find out what its figures are compared to the rest of the pack.

DryIocZero and Cauldron with best results are out of Prepare chart.

It makes results more accurate because of there are no any additional operations of conversions of type. Actually it is more sensible scenario to use these methods and all IoC containers have these methods

Will it make sense to use it here?

At the moment the benchmark contains 35 containers.

Question 1: Should containers be categorized as relevant / not relevant for the benchmark?

Question 2: Based on which criteria should containers be categorized as relevant / not relevant?

• Only few months of history
• Not actively maintained
• Few features, no integration options
• Few contributors

Question 3: What should happen with containers that are not relevant

• Completely remove them from the benchmark
• Create a separate list with legacy / not relevant containers

Examples:

I do understand, that it may be an acceptable error delta. But looking side-by-side the results look weird and doubtful.

So may be, we can be measure differently: like measure Register then measure Resolve, and then just sum-up the results for the Register+Resolve?

Love this benchmark!

Change the custom benchmarking infrastructure to use BDN, it's the de-factor benchmarking tech for .NET projects now and it'll likely produce more accurate results and more detailed measurements (like allocations etc).

/cc @adamsitnik @AndreyAkinshin @mattwarren

https://github.com/aspnet/DependencyInjection

Possible to benchmark this guy too?

The new url is catelproject.com instead of catel.codeplex.com

This has been brought up in the past, but TinyIOC is one of the largest IOCS out there and should be included in any metrics.

The old issue mentioned VS2017 as the limiting factor, but since we are now on VS2019 and TinyIOC has been updated along with it I feel this warrants being brought up again.

Please add TinyIOC to the comparisons in the future. I believe a lot of people would appreciate this.
Thanks

Might be interested to see this one. Thanks!

can't seem to find them?

A common architecture on projects I work on is to allow multiple scopes per controller, where the controller is an entry point for parallel processing some work. For example, creating multiple DbContext objects, one per parallel unit of work. Since DbContext is not thread-safe, a Func<DbContext> is required with a way to OpenScope on the existing scope, creating a new scope that is either a child/nested scope or orthogonal scope to existing scopes.

Issues I have come across implementing this pattern include threading security context (authentication and authorization) to the parallel unit of work, as the child threads do not inherit the identity context, so the identity has to be thunked to the child threads.

It is mysteriously missing from the list in the main page:
https://github.com/danielpalme/IocPerformance

Even though a quick search shows some references to it in the code...

https://github.com/TinyMapper/TinyMapper

Real worlds scenarios involve complex object graphs. Some containers could work better or worse in such case. So current tests make me to doubtful about results as using small amount of types may lead to false results. I going to write .tt file which generates and registeres 200 classes into 3 most fastest containers and Autofac and DryIoC.

My setup will be Layered HTTP Web API like backed application.

Controller depends on Services depends on UnitOfWorks depends on Repositories. All may by even/odd or other rule depend on IEventing/ILogging/IEnvironemnt etc. All resolution is done via constructors.
Controller resolved per request. Other layers are shared for that Controller, e.g IUnitOfWork1 resolved by Service1 and Service2 is reused for Controller. IEnvironment is singleton. IAuthorization and IRouting implementations are chosen and resolved depending on current HTTP headers.

Containers resolution is done in 4 threads to imitate concurrent workload.

Results of these tests should be placed into separate spreadsheet graph.

Another options are console or desktop or mobile app.

Seems Prepare And Register and Prepare And Register And Simple Resolve broke Advanced features chart. May be create separate chart for these, this will fix issue and may allow somebody add different initialization routines (e.g. XML, assembly scan or out of previously cached container registrations).

I was looking at the Warmup method in Program.cs

    private static void WarmUp(IContainerAdapter container)
    {
        var interface1 = container.Resolve<ISingleton>();
        var interface2 = container.Resolve<ITransient>();
        var combined = container.Resolve<ISingleton>();

        if (container.SupportsInterception)
        {
            var calculator = container.ResolveProxy<ICalculator>();
            calculator.Add(1, 2);
        }
    }

I believe the third line should be Resolve ICombine not Resolve ISingleton, it doesn't really make much of a difference in the results just something I noticed.

Severity Code Description Project File Line Suppression State
Error CS0116 A namespace cannot directly contain members such as fields or methods IocPerformance D:\Code\IocPerformance-master\IocPerformance\Adapters\DryIocZero\Container.Generated.cs 1 Active

Building with 4.7.2.

Deleting the contents of this file allowed it to build and execute successfully. Downloaded projects should just "work" out of the box, without the need to understand build errors.

is low better or worse, its not clear

as the graphs contradict the results then

Unity 5.11.10
 | 216 148 | 1443 835 | 3326 1995 | 9503 4739

Microsoft Extensions DependencyInjection 6.0.0 
| 65 57 | 108 82 | 108  109 | 150  115

This would indicate that the Microsoft Extensions DependencyInjection is faster yes?

but then in the graphs it shows it like how many instances were created over time

https://danielpalme.github.io/IocPerformance/

So then actually Unity is faster...

Hi Daniel,

I was hoping to get StyleMVVM added to the list of containers.

I've put together an Adapter that can be found on dropbox with the link below, so you should just be able to add the StyleMVVM nuget package then add the adapter.

https://www.dropbox.com/s/fj5ukhqf1v1eexg/StyleMVVMAdapter.cs

The numbers I'm getting put it as one of the faster "avergage" containers while support advanced features like Lifecycle containers, conditional exports (similar features as ninject conditional binding), Open Generic exports and more.

thanks
-Ian

As they reflect real usage more precisely than single threaded tests.

Noticed that the current benchmark does not measure the multithreaded performance accurately enough, especially when containers like singularity can do their work in less than 10 nanoseconds. I believe this is because there's too much overhead in the way the benchmark is done currently. Increasing the sample size might lead to more accurate results.

When you do this you will see that for alot of containers the multithreaded results will be faster like they should be.

It seems you configure Unity with Interceptors for all of you tests. Interception introduces reflection into building strategy and is rather slow. It skews results dramatically.
I would suggest either creating two adapters with and without interception or configuring Interception only if it is required by the tests.

Most of the containers do not have interception so it creates unfair advantage when compared to the Unity. To give objective performance comparison the playing field should be leveled.

As you can see in these tests your results are way off.

I would like to suggest a small improvement to your benchmarks. It has to do with how your setup threats interception.

Generally interception extension severely degrades any container's performance. (Unity, for example, does not recommended it for new development). I once sent you a PR with removed interception, but you added it back.

If you insist on testing interception, perhaps you could test it as a separate case and load the extension only for interception benchmarks? Right now you are loading it for all tests and slow container down by order of 2 or 3.

This issue affects all containers with support for interception and skews results in favor of containers without the interception support.

To demonstrate my point here are few numbers:

This is how for your benchmark setup by default:

Unity 5.11.7                                 Single      Multi
 Singleton                                      166        105
 Transient                                     1092        582
 Combined                                      2651       1388
 Complex                                       6600       3407
 Property                                      6690       3536
 Generics                                      6119       3173
 IEnumerable                                  12140       6706
 Conditional                                   2337       1222

and this is benchmark with disabled interception:

Unity 5.11.7                                 Single      Multi
 Singleton                                      202        112
 Transient                                      270        159
 Combined                                       945        540
 Complex                                       2955       1608
 Property                                      3137       1672
 Generics                                      2501       1320
 IEnumerable                                   4255       2655
 Conditional                                    599        338

The difference is quite significant.

With many of the containers supporting asp.net core out of the box it would be interesting to see a benchmark to represent a request.

I think it would be something like

• Resolve IServiceScopeFactory

• Call IServiceScopeFactory.CreateScope

• Resolve ISingleton1,2,3 services

• Resolve Transient disposable that is dependent on a hierarchy similar to Complex but use a singleton per request lifestyle vs singleton

• Dispose IScopeProvider

• at the end check to make sure everything is disposed correctly and counts for singleton per request.

I'd be willing to write the test and setup adapters that have published nuget packages for Microsoft.Extensions.DependencyInjection.

The original child container test isn't meant to cover this type of use case and isn't representative of ASP.Net Core per request.

Thoughts?

Should be fairly easy to add?

https://github.com/Microsoft/vs-mef

I noticed this when looking into a couple of the IoC listings.

The DryIoC BitBucket says the following:

The new DryIoc home is on GitHub: https://github.com/dadhi/DryIoc

I think the readme should point at the most up to date place.

Hey guys, I've just released Castle Windsor 4.0.0 which supports .NET Core and Castle Core 4.0.0.

https://github.com/castleproject/Windsor/releases/tag/v4.0.0

Please, can you commit/push the newest README.md that matches the results on your blog? :)

Hello, trying to build fresh repo checkout of version e9365e6.

Packages cannot be restored because of this error:

NU1608: Detected package version outside of dependency constraint: Ninject.Extensions.ChildKernel 3.2.0 requires Ninject (>= 3.2.0 && < 3.3.0) but version Ninject 3.3.4 was resolved.