What does the MVC framework do to avoid low performance that it inherits from the heavy use of reflection

While writing MVC views I see a lot of call to Html helper m开发者_StackOverflow中文版ethod such as EditorFor/LabelFor. These extensions use a lot of reflection behind the scenes. Coupled with how routing, model binding, validation, EF manipulation ... are all handled via reflection, I wonder how much it hurts performance?

I want to know what MVC framework does under the hood to tackle the implications of using reflection on such a large scale.

I'm sure it must be doing some kind of caching, but knowing what it exactly does will be a good learning experience and assurance that we are not compromising huge performance for the sake of some productivity gain.

---

As marc_s said in the comment using reflection is not necessarily a bad thing. I'm responsible for a lot of the performance investigations for MVC (and I even wrote a few blog posts on MVC performance) and the biggest perf issue in real world applications is database access. Everything else pales in comparison.

But we do try to keep the core framework as lean as possible and so we do caching where appropriate. This includes view file lookups, model lambda expressions and a whole lot more. The easiest way to learn about this would probably be to look at the source code and find places where we use Dictionary<Type, T>, MemoryCache, or HttpContext.Cache.

Another way would be to actually run an Mvc application under a profiler, but that's a bit more advanced topic (though if you search for it you'll get some good hits).

In the end you have to trust us that we are doing the right thing :) We have already optimized a lot of the perf issues and the remaining reflection usage just does not have that much of an impact.

And here's a greate video from Steven Smith on tuning the performance of an MVC application: http://channel9.msdn.com/Series/mvcConf/mvcConf-2-Steven-Smith-Improving-ASPNET-MVC-Application-Performance