I have a GridView which is inside an update panel that returns data from an ORACLE stored procedure.  The stored procedure in PL/SQL developer takes 2 seconds to return data, when I have it in the Update Panel filling the GridView it takes 20 seconds, 18 seconds without the update panel. 

It is using a DataTable object to bind to the grid.  What do you think is causing such latency?  I have debug=false in the web.config but this has me quite confused. 

Does it return a lot of data? GridView stores the entire dataset in the ViewState, on big query you can end up with a ton of page bloat.

47 rows is my largest result and debugging is false in my web.config, paging is set to 10.  The query returns results in 1-2 seconds in PL/SQL developer, but when I hook it to an ASP.NET page it takes 20-30 seconds and does not matter if I have an updatePanel or not!

Check out the "__VIEWSTATE" hidden field though. If they are big objects, you could still be talking about a 150k page, even if you wouldn't think it would be that big.

How do I access that?  I also dump my results into a ViewState["DataTableSearchResults"]  

The reason I put the results in ViewState is because I have a search screen with different criteria.  I also have paging and sorting enabled and if I don't put it in ViewState I loose the data.   

View page source on the rendered page.

I'm almost positive thats where your perf issues are coming from. The ViewState works by serializing/encoding its contents and sticking them on a hidden field. Both Partial and Full page postbacks will push the viewstate over the wire in both directions.

There are a bunch of places you can store stuff in asp, each has its pro's and con's. First thing though is are you using the automagical (like editing) stuff in your grid, or is it  display only? If it is display only, stick EnableViewState="False" in it, that will make a big difference.

As for the search results,  If it is  something  that will be the same for everyone  (not based on dynamic criteria), I would stick it in the cache object. If it is the results of a search screen, I would probably use the session, not the view state. Filling up the session is still not that great, as it is in-proc memory for each active user, but in this case it is probably a better then serializing to the page. General rule of thumb is ViewState for smaller things, Session for bigger things (not quite that simple, but it is better then just viewstate for everything)

 

I really can't cache this because there are so many different variables in the search criteria it would almost be a new search everytime anyway.

Hi commadercody,

First you can disable ViewState. Second you can use custom paging stored procedure which means it returns only one page data (in your case it is 10 records) at one time.

Here is an article about it: http://www.dotnetjunkies.ddj.com/Article/975BE770-E5DC-4610-870B-A82BDB9B8845.dcik

This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.