I have Mini-Profiler installed on a new MVC4 site and notice a big wait time for certain Find: DisplayTemplates including String and DateTime. Below is an example. In another question, Sam Saffron said this about the find step
On subsequent runs it is lightning fast (unless you have something really bad going on)
But the following happens on every page load:
http://localhost:80/SLS.Site/s/hogwarts/lunch... 2.6 +0.0
Check School Permissions 2.4 +2.0 1 sql 0.9
Controller: SchoolAdmin.LunchGroupsController... 4.0 +4.5
Find: Index 0.4 +8.6
Render : Index 70.0 +9.1 2 sql 13.0
Controller: SchoolAdmin.LunchGroupsController... 2.6 +12.3
Find: BuildingTree 0.4 +14.9
Render partial: BuildingTree 4.4 +15.4 1 sql 3.2
Controller: SchoolAdmin.LunchGroupsController... 3.3 +20.2
Find: Teachers 0.6 +23.6
Render partial: Teachers 4.3 +24.3 1 sql 2.4
Find: DisplayTemplates/String 409.3 +31.9
Render partial: _UserContext 0.0 +441.3
Find: _LoginPartial 1.2 +441.4
Render partial: _LoginPartial 0.2 +442.6
3.9 % in sql
Any thoughts?
Edit
I had 4 areas setup, so I figured it was traversing all the directories looking for a match, so I removed 2 of the areas and have the same behavior.
I had EXACTLY the same issue... after some searching around I found I was using:
@DisplayFor(x => x.StringProperty);
After thinking about it, and finding out about how all the DisplayFor/EditorFor methods work from making some templates myself, it made no sense.
(A bit of explanation on how DisplayFor/EditorFor works)
When using DisplayFor/Editor for, MVC gets the type of object and then searches the Views/ControllerName/DisplayTemplates directory for a view with the same name as that type, in this case, it's searching for Views/ControllerName/DisplayTemplates/String.cshtml. As it doesn't exist, it also does the same in the Shared/DisplayTemplates views directory, again, it won't exist.
(This next bit is speculation)
I would presume that as it can't find the relevant Display/Editor template, it then performs a ToString() on the object, as a fail over.
As you are only displaying a String type anyway, it would make sense to not use the DisplayFor(x => StringProperty) and just use @Model.StringProperty, which would not cause MVC to search for a DisplayTemplate, and just render it as a string, which it's going to do anyway.
Once I put a profiling block around the bundles in the <head> I could see where the time was really being spent. Mini-profiler was misleading me, originally: the time was not spent in DisplayTemplates/String but elsewhere!
In my case, the delay was happening in MVC4 RC's script bundling.
I removed the bundles and all is good.
See related issue below:
来源：https://stackoverflow.com/questions/11758338/find-displaytemplates-speed