Does dependency injection potentially cause large overhead?
I would imagine so, especially if the resolver is called many times (which is quite likely looking at pattern examples)? Or am I thinking wrong? Unfortunately I can't test for myself as I have never used it but planned on using it.
Dependency injection as a concept need not have high overhead: it's simply structuring a class so that its connections to other classes can be constructed at run time rather than being hard-wired in the code.
Of course, there are ways to build that run-time connection that might have high overhead. Avoid those ways.
Dependency Injection per se is just a simple indirection, so there's overhead but it's pretty minor indeed. Runtime pattern matching and resolving is another thing (but while often used with Dependency Injection, it's not as if DI demands such extras;-).
Unless you're using a service locator, I doubt that the overhead will make a significant difference. (Even if you are, it's unlikely to be significant.)
Using constructor injection and a modern framework, the resolver will get called when objects are constructed. For the most part I suspect you'll find that the objects with dependencies are relatively high-level components, long-lived, or both.
If you're using an IoC container and creating a lot of objects with dependencies in a tight loop, you might need to do some optimization. You could always profile or benchmark it.
In short, I wouldn't worry about it.
Dependency injection is not going to give huge overhead. I'm sure you'll find bottleneck somewhere else. If you are concerned so much about overhead may be C# is not the language you want to use. You use C# for benefits it's brings, it abstracts some details you don't want to deal with.
The same with DI, it also has benefits like making your application loosely coupled and that means that it will be easier for you maintain it in the future.
http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html for some performance testing. Each test was running 1000000 creations.
Note that the benchmark shows singleton resolution and transient resolution: a singleton is there you register an instance of a class e.g. (using Unity):
container.RegisterInstance<IMyType>(new ConcreteMyType());
and this instance is returned every time (which is quite quick).
A transient is where you register just the class type and the IoC framework will do the job of creatnig it for you e.g. (in Unity)
container.RegisterType<IMyType, ConcreteMyType>();
This takes more time that returning a singleton.
In terms of overall optimisation, the overhead of the dependency injection is small beer; other performance bottlenecks are more likely to be the things to optimise.
Overhead vs testeable and maintainable code ... I choose testeable and maintainable code (you can always buy a faster computer)
=)