views:

266

answers:

2

Does anyone have any ideas or references they could point me to regarding optimizing the viewstate of my ASP .NET application? I don't want to turn it off all together, and the main goal of optimizing it is to speed up performance so I don't want to run an expensive function to recursively disable the viewstate for certain controls because that function would slow down the load time of the page which would defeat the purpose.

Any ideas?

+4  A: 

There's not a lot I can tell you except "don't put a lot into your ViewState".

Places I'd look for optimizations:

  • Anything you added to ViewState yourself
  • Large amounts of data bound to data display controls like GridViews, <x>Lists, and Repeaters.

GridViews are particularly bad about ViewState; everything you databind goes into it, so if you bind a particularly large list expecting ASP.NET to handle pagination of it for you, you're going to have a huge ViewState. The only way to get around this is to only bind one page at a time to the GridView, but that means you'll have to do data-side pagination which can be just as painful, or to turn off ViewState for the GridView, which means (arguably) useful features like in-line editing are no longer available.

There's no silver bullet here.

Randolpho
At first I was trying to figure out a way to accomplish viewstate optimization system wide but the more I think about it the more I'm coming to the conclusion that this will have to be a control-by-control thing. Thanks!
Adam
+4  A: 

Here are some ideas how you can optimize the size of ViewState transferred over the wire (copied from this answer):

  • Disable ViewState for controls that do not need it (this is the most effective solution). E.g. if you can cache some data on the server, then you can re-bind any databound controls with every request and it's not needed to save everything in ViewState.
  • Turn on HTTP compression on the server (IIS). This reduces the size of the page sent to the client, including the ViewState.
  • Compress the ViewState. This has an additional advantage over HTTP compression: it also reduces the size of PostBacks (data sent back to the server), since the ViewState is always sent back to the server during a PostBack. There are various approaches for this, e.g. as shown in this blog post.
  • Store the ViewState on the server instead of sending it in a hidden field with the page. The easiest way to do this is to use the SesionPageStatePersister, but there are other solutions which store the ViewState to disk instead of using the Session (see here for example).
M4N
Great! Thanks! Do you know roughly if viewstate compression and storing the viewstate in the session are expensive as far as server execution goes. I'm still going to try those two out on Monday just to test it with my application but I was wondering if you've had good/bad experiences with those in the past with regard to how much it slows down the server.
Adam
I have used the fourth approach for a web application which tended to produce lots of ViewState. The application was only used by a small number of users at any time, so in that case the increased memory usage was not a problem. I made some tests with the third option, but have until now not made any tests/measurements (never used it in production). Generally I try to disable/minimize ViewState as much as possible (option 1).
M4N