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.
BradBates Oct 20, 2010 01:16 AM
Make sure that you have debug = false in your web.config.
bradwils Microsoft Oct 20, 2010 04:07 PM|LINK
It is a lot faster with debug set to false. What is the reason behind the huge difference in performance between debug set to on and off?
When debugging is on, we don't cache the mapping from view name to view file, because we assume that during development you will be adding/deleting views on a regular basis. This is made worse by the fact that, in MVC 2, we're calling an API that normally throws an exception when the view file isn't found, so a simple lookup of a template might cause several exceptions to be thrown. In MVC 3, we're using a new API in ASP.NET 4 which allows us to bypass this exception.