Unfortunately my speed problems with grid far from over and I’m still trying to figure out avenues to address them.

Here is the setting :

Hierarchical grid with three type of child grids binding of the data set with one master table and three child tables with relationship set.  Originally it was load on demand setting that actually was abandoned last moment before production release, It was extremely slow of opening child grids and actually because of requirements to

recalculate values on master grid full postbacks were needed and speed of opening child grid were getting worse with every use.. fast forward, now each child grid is separate predefined band and initial depth set to 1 so there is no postback while data get entered ( all grids are batched, it caused additional issues for load on demand case )  and everything working except one child grid needs add record functionality and adding it bring the whole page to complete stagnation... so for that grid 50 records pushed to create space for entering new data and import created if users need more...

The whole size of data set as following :

Master data table : 260 records

Child grid type 1   : 1550 records altogether means spread between 30 grids ( 50 each, but can be more )

Child Grid type 2  ; 80 records altogether

Child grid type 3  :  10 records altogether

Here the timing  ( IE 8.0 official co browser ) :

Initial load time for the whole page : 40 secs  

Page size ( shown by fiddler ) : 960,551 bytes

if mane grid paged 20 rec/page and Child Grid type 1 paged 10 record per page

Initial Load  16 sec  page size 600,000 bytes, still too big and not flying...

paging : main grid 6 secs , type 1 child 9 secs - this is not acceptable,rather have user to wait initially.

Here what I would like to know : If there are ways to somehow reduce size of the page , may be somehow reduce size of ViewState, Yahoo mail paging happening almost instantly...

I’m looking for other approaches if any on the top what was already discussed ( load on demand and paging).

Thanks

Column count :

parent 7 columns ( including 4 hidden )

type 1  8 columns ( including 3 hidden)

type 2  6 column  ( incl 4 hidden )

type 3  7 columns ( including 3 hidden )

Initialbinddepth set to 1 so everything get rendered upfront, so far this is only way page became operational...  ,

Are there any other ways to reduce view state  size.. or anything else can be done to speed it up..

Attached is source view of the page, may be something is there that I did not noticed...., do this controls can operate without writing into viewstate ?  Anyway, do you have any approach to reduce size of the rendered page ?

Data get stored in the session : retrieved once and maintained there until saved... the big grid on the first tab also some filtering capabilities implemented, the rest seems like minor addition, here is the binding on the page load and the mark up page attached:

if (IsPostBack)
            {
                if ((ExhibitLR2MasterDS)Session["ExhLR2MasterDS"] != null)
                {
                  //  ExceptionUtility.LogException("Due~~PageLoad PostBack, Data exists: " + DateTime.Now.ToString("MM/dd/yyyy hh:mm:ss.fff tt"));
                    ExhibitLR2MasterDS MasterDS = (ExhibitLR2MasterDS)Session["ExhLR2MasterDS"];
                    ExhibitLR2MasterDS.ExhLR2MasterTblDataTable MstTbl = MasterDS.ExhLR2MasterTbl;

                    uc_top_refresh.wddTopAcctFilters.AutoPostBackFlags.ValueChanged = Infragistics.Web.UI.AutoPostBackFlag.On;
                    string filter = uc_top_refresh.wddTopAcctFilters.SelectedValue;
                   
                    if (hdnAccountFilterVal.Value != filter)
                    {
                        hdnAccountFilterVal.Value = filter;
                        whdg.GridView.ClearDataSource();
                        whdg.GridView.Rows.Clear();
                        MstTbl.DefaultView.RowFilter = filter;
                        whdg.DataSource = MasterDS;   // (ExhibitLR2MasterDS)Session["ExhLR2MasterDS"];
                        whdg.DataBind();
                        whdg.GridView.RequestFullAsyncRender();
                    }
                    else
                    {
                        MstTbl.DefaultView.RowFilter = hdnAccountFilterVal.Value;
                        whdg.DataSource = MasterDS; // (ExhibitLR2MasterDS)Session["ExhLR2MasterDS"];
                        whdg.DataBind();
                    }

                    ExhibitLR2DetalsDS ExhLR2DetailsDS = (ExhibitLR2DetalsDS)Session["ExhLR2DetailsDS"];
                    wdgSrv.DataSource = ExhLR2DetailsDS.SurveyTbl;
                    wdgSrv.DataBind();
                    // SynchronizedExtra();
                    //BindExtra();                  
                }

While trying to avoid premature optimization scenarios I'm trying to find a culprit... I do not believe that it is network, running browser on the server producing almost the same results....  as for other controls - page has some but it's just another grid with really small data set and drop downs and text boxes ( you've seen the page ), what I'll do when chance is create page with just this grid and see how it perform...  we can close this thread for now but rather get back to it when page with single grid results will be available .

I still did not have a chance to get back to this part of the project... Here I would like to know a bit more about paging :

Say I have 1500 child records about 100 per child grid.  Say I page by 10 records every child grid.  So the child grid will be bind to 100 records, only 10 displayed at once, when I click next then 10 other records displayed ... is that 10 records choose when grid gets bound... so 90 records not getting rendered to the browser and only 10 do...

If ajax is enabled so only partial update happen and if it is only 10 records why it does take so long ( about 8 sec ) ?