Reputation: 1844
It takes a long time for my view to render. It consists of a table populated from about 90 table records. The dB calls are running very quickly, but it takes a while to display all the records. Here is the bit of code causing the sluggishness:
<table>
@for (int i = 0; i < Model.PositionEdits.Count; i++)
{
<tr>
<td>
@Html.DisplayFor(x => x.PositionEdits[i].PositionID)
@Html.HiddenFor(x => x.PositionEdits[i].PositionID)
</td>
<td>
@Html.DisplayFor(x => x.PositionEdits[i].PositionDescr)
@Html.HiddenFor(x => x.PositionEdits[i].Description)
</td>
<td>
@*editable*@
@Html.DropDownList("Position",
new SelectList(Model.Positions),
Model.PositionEdits[i].Position)
@Html.HiddenFor(x => x.OldPositions[i].Position)
@Html.HiddenFor(x => x.PositionEdits[i].Position)
</td>
</tr>
}
</table>
I realize that paginating would solve my problem, but I was hoping to show all ~90 records on the same page. Is there a way I can improve this view to decrease load time?
Upvotes: 0
Views: 277
Reputation: 239290
First and foremost, if you're still in local development, especially if you're using debug in Visual Studio, it is the absolute wrong time to worry about things like page load times. You're dealing with a very light-weight single-headed server with tons of overhead caused by the integration back and forth with Visual Studio and its tooling. Page load times are meaningless.
Once you've got something workable, you can deploy it to a production-ready server environment to test performance. Unless you're running on full blown IIS on a dedicated web server with the actual RAM and other resources you plan to devote to the site in production, any measurement of performance is meaningless as it's out of context.
If it's still slow, which I don't see any way it possibly could be (90 records on an actual web server with full IIS with even a modest amount of system resources is trivial), you'll need to investigate what part is really slowing you down. There's time involved in the initial transmission of the request, database queries, the actual server time generating a response, time to send that response back to the user, time it takes for the browser to render the HTML and CSS, issue requests/receive responses for additional resources like CSS, JS files and images, and time to execute any JS on the page.
Using the developer tools of your browser (Chrome has a particular good set in this regard), you should be able to see a gantt chart indicating when each request was issued and how long it took to get the response. That only tells part of the story though. You'll need additional tools to dig deeper once you find some problem areas to look at. I personally use Glimpse. This will give you very detailed information about how long just about every part of the process took and what pieces of your application are slowing you down. The steps you need to take to fix the problem will largely depend on what is actually causing the problem, which so far is still a mystery.
Upvotes: 1