Comments on Coding Instinct: IoC Container Benchmark - Unity, Windsor, Structur...

You clearly don't know Jeremy Miller very well if ...

2008-07-06T17:31:00.000+02:00

You clearly don't know Jeremy Miller very well if you think that's what'll happen with StructureMap.

I think what this page shows is that using IOC con...

2008-06-16T06:24:00.000+02:00

I think what this page shows is that using IOC containers will not make your app significantly slower. What makes apps slow are poor design, bad databases, and network latency.

As to which one to use, you have to try and figure out which one has a future.
I would rule out Spring.Net because it is a Java port and will always be several steps behind in supporting the latest .Net framework features.
StructureMap is cool but since only one guy is supporting it I would expect the project to die once that dude gets tired of dealing with it.

Unity may be the safe bet being that it has "Official" support from Microsoft. The MS guys where starting to promote this at TechEd this year. On the other hand, don't expect any innovation from Microsoft.

If you want a supported component, go with Unity. If you want innovation, go Windsor.

I think the comment about functional differences i...

2008-04-20T08:09:00.000+02:00

I think the comment about functional differences is important - what are you getting for you time?

In a real app with more components, the factors affecting container performance will shift from the expense of creating instances, to the expense associated with algorithms that are affected by the number of instances (e.g. which instance from many should be returned?) and algorithms that take a time proportional to the size of the dependency graph (e.g. circular dependency checking.)

You can never tell where that performance bottleneck is going to be until you measure it ;)

Nice benchmark. A functional comparison for the us...

2008-04-17T09:20:00.000+02:00

Nice benchmark. A functional comparison for the used Ioc Containers would be interesting. Where do the performance differences come from?

Well the point was to check if there was any relev...

2008-04-16T22:41:00.000+02:00

Well the point was to check if there was any relevant difference, not to check which was the fastest.

And I think you can actually disregard a relative difference if that difference is still not relevant when you look at the absolute performance.

My conclusion to the test was that the relative difference was too small to make any relevant difference in real applications.

I'm sorry, but if you are going to do a test and f...

2008-04-16T22:09:00.000+02:00

I'm sorry, but if you are going to do a test and find a huge relative difference, you should not disregard it by looking at the absolute difference. What's the point in doing the test than?

I think it's pretty clear that no container takes a very long time, so what were you hoping to find?

(no disrespect meant, I clicked on the post because I was curious as well ;-) )

Nice post. I'd also be interested to know how Ninj...

2008-04-16T21:43:00.000+02:00

Nice post. I'd also be interested to know how Ninject does in comparison. :)

Bil's right, though, that it wouldn't typically make a difference, because most applications don't need to create 1,000,000 instances. However, faster IoC also means that you can use it in places that you wouldn't otherwise be able to -- for example, devices that support the compact framework.

Still a worthwhile study, and it's interesting to see the results!

Yes, I agree that this is not a realistic scenario...

2008-04-16T16:25:00.000+02:00

Yes, I agree that this is not a realistic scenario. Doing one million resolves is not something that do in one request. That was just to accumulate the performance difference to see if there were any substantial difference.

I don't think it was a waste of time, because it could have potentially been a big meaningful difference between them. Now it turned out that there weren't but that didn't make the test meaningless, because now you know :)

This is interesting but IMHO a bit of a waste of t...

2008-04-16T15:53:00.000+02:00

This is interesting but IMHO a bit of a waste of time. I mean, what application would *ever* need to try to create a million objects all at once? Even in a tight loop you *might* create a few thousand objects. I just can't think of any use case where this situation would ever manifest itself so to me the numbers are pretty meaningless. Interesting to look at, but not of any value to judge something by. If the differences were significant with say a few hundred objects then maybe this exercise would be worth something.

I guess it should have been in the test having a s...

2008-04-14T19:40:00.000+02:00

I guess it should have been in the test having a slogan like "Lightning-fast dependency injection for .NET"

Hopefully I will have time to do it later in the week, thanks for the tip!

I would interested to see how Ninject compares.

2008-04-14T18:57:00.000+02:00

I would interested to see how Ninject compares.

Yes, you are right. I also feel that the last grap...

2008-04-14T13:25:00.000+02:00

Yes, you are right. I also feel that the last graph is too misleading. I will correct it when I get home from work.

IMHO your last graph is very misleading. why do yo...

2008-04-14T13:20:00.000+02:00

IMHO your last graph is very misleading. why do you use the inverse values? use the usual values and point out how tiny the "new" value is - or if you feel like the inverse is beneficial at least label your axis correctly.

otherwise nice article