This project is read-only.

Faster mechanism than Activator.CreateInstance?

Feb 14, 2013 at 8:22 PM
Feb 14, 2013 at 9:44 PM
Why do you assume that Simple Injector would ever use Activator.CreateInstance? Have you ever did a performance benchmark, read this discussion or read an article that benchmarks DI containers (such as this one)?
Feb 14, 2013 at 9:52 PM

I didn’t say I'd measured it, or that it was slow, and I'm very happy with SImpleInjector. I've seen the benchmarks before. I just wondered what had been thought about and hence the discussion.

Actually, Activator.CreateInstance does appear in 5 places in the source code which is why I asked, as does GetConstructor(). Although I see the latter looks like it's using Expressions already.

Thanks for the link - that helps clarify for me.

From: dot_NET_junkie [email removed]
Sent: 14 February 2013 21:45
To: Daniel Sinclair
Subject: Re: Faster mechanism than Activator.CreateInstance? [simpleinjector:433191]

From: dot_NET_junkie

Why do you assume that Simple Injector would ever use Activator.CreateInstance? Have you ever did a performance benchmark, read this discussion or read an article that benchmarks DI containers (such as this one)?

Feb 14, 2013 at 10:14 PM
Edited Feb 14, 2013 at 10:16 PM
You analyzed the source code? That's what I like to hear :-)

It's true, Activator.CreateInstance is used now and then. It's however only used in places where they make sense. You won't find calls to Activator.CreateInstance in the happy path of the application. In the happy path there are only compiled Expression trees and cached Func<T> delegates (no locks either).

Activator.CreateInstance makes sense in initialization code. This is code that is only ran once. Here you don't want do expression tree compilation, since this has a big performance hit when it is called once (and it is definitely slower than Activator.CreateInstance and it consumes a lot of memory). But more importantly, in parts of the system where performance is not an issue, I pick the construct that is easiest; most maintainable. I try to prevent premature optimizations and often run benchmarks to see if all types of registrations are fast. Not only for simple things like Register<TService, TImpl>() , but also for things like RegisterDecorator and RegisterOpenGeneric . Although they do have impact on the performance in the initialization phase, the performance is one time and after that, they are as fast as normal Register<TService, TImpl> registrations.
Marked as answer by dot_NET_Junkie on 11/5/2013 at 7:34 AM