Yeah, we've seen this.

Two things:

1.
Have you seen the code for this benchmark? Func and SM are so fast 
because they behave like a dictionary: Type => .ctorCall
Windsor does full dependency resolution and matching and a LOT more, 
hence it's slower.

2.

I updated the benchmark (and fixed a bug in it - they were registering 
ILogger twice for Windsor) to use the latest (trunk) version of Windsor, 
and re-ran the benchmark (on my AMD Phenom).

Running 1000 iterations for each use case.
No DI          :    1253 ticks
Funq           :    5984 ticks
StructureMap   :   29860 ticks
Unity          :   76193 ticks
Autofac        :   79813 ticks
Windsor        :  274807 ticks
Ninject        :  468988 ticks
Ninject2       :  480739 ticks

As you can see for this case Windsor is now ~2x faster than before 
(relatively to other containers).

Final words
I would NOT pay too much attention to benchmark like this. The only true 
benchmark - production, which was ran for Windsor thousands of times 
shows it is fast enough, and as soon as you start having more than 6 
components its rich featureset and pluggable architecture will outweigh 
the performance difference as compared to other containers.


bling wrote:
> Look at the source found here:
> http://funq.codeplex.com/SourceControl/ListDownloadableCommits.aspx
>
> The performance test wasn't complex at all...it was simply all
> transient instances.
>
> A depends on BC
> B depends on EFG
> C depends on EFG
> E depends on FG
>
> That's pretty much it....
>
> Here are the results on my Core2Duo:
>
> Running 100000 iterations for each use case.
> No DI: 0.52658
> Funq: 5.12918
> Unity: 70.50138
> Autofac: 84.43523
> StructureMap: 24.09755
> Ninject: 445.10718
> Ninject2: 569.03438
> Windsor: 566.37271
>
> Pretty much every IoC container involved surprised me.  I did not
> expect StructureMap to be this fast, nor did I expect Ninject to be
> the slowest!
>
> Can performance be improved?
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Castle Project Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/castle-project-users?hl=en.
>
>
>   

--

You received this message because you are subscribed to the Google Groups 
"Castle Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en.


Reply via email to