What MVC infrastructure does to avoid the low performance it inherits from heavy use of reflection

Question

While writing MVC views, I see many calls to the html helper method, such as EditorFor/LabelFor . These extensions use a lot of reflection behind the scenes. Combined with the way routing, model binding, validation, EF manipulation ... are handled through reflection, I wonder how bad it is for performance?

I want to know what the MVC structure does under the hood to solve the consequences of using reflection on such a large scale.

I am sure that he should do some kind of caching, but knowing what he is doing will be a good learning experience and the certainty that we do not jeopardize tremendous productivity in order to increase productivity.

Answer 1

As marc_s said in a comment, using reflection is not necessarily bad. I am responsible for a lot of MVC performance research (and I even wrote a few blog posts about MVC performance ) and the biggest performance in real applications is access to the database. Everything else pales in comparison.

But we try to simplify the structure of the kernel as much as possible, and therefore we do caching where necessary. This includes browsing for search files, modeling lambda expressions, and more. The easiest way to find out about this is to probably look at the source code and find the places where we use Dictionary<Type, T> , MemoryCache or HttpContext.Cache .

Another way would be to run the Mvc application under the profiler, but this is a slightly more complicated topic (although if you find it, you will get good hits).

In the end, you must trust us that we are doing the right thing :) We have already optimized a lot of performance, and the remaining use of reflection simply does not have such a big return.

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