5

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.

Community
  • 1
  • 1
Joey Gennari
  • 2,361
  • 17
  • 26
  • I just did a test after having a similar problem. It seems that a significant amount of work is deferred until the first call to DisplayFor, so the time gets bloated – Ethan Reesor Aug 14 '14 at 01:29

2 Answers2

3

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.

Stuart.Sklinar
  • 3,683
  • 4
  • 35
  • 89
  • 3
    It's a shame this isn't the accepted answer, because it's good advice. The `Find:DisplayTemplates` stuff is really slow, and unless you're doing some complex templated rendering, just directly use the values from the model. Avoid `Html.DisplayFor` like the plague. – Jez May 01 '13 at 13:31
  • 2
    Cheers - Good skills on `Html.DisplayFor`, I've seen a few speed issues there too! As you say, avoid it unless you're using your own templates! – Stuart.Sklinar May 01 '13 at 13:44
2

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:

MVC4 RC script bundling very slow

Community
  • 1
  • 1
Joey Gennari
  • 2,361
  • 17
  • 26
  • 1
    The important thing here is that the issue can definitely be related to something other than the DisplayFor. The performance issue I was looking for was an AD lookup on each item in our menu. The key lesson from this answer is to widen your search otherwise MiniProfiler's default categorisation may lead you astray. – Rhys Parry Dec 11 '13 at 00:49