Page Processing Speed

[Joe Reazor]

I've got an asp.net page that has approximately 1,440 controls on it. You
must think I'm crazy, but we need to have the page organized in this
fashion. As you can imagine, the page takes a very long to to process, on
the order of 20-30 seconds, even though only a small number of the controls
are generally visible at once it still has to process all the controls on
the page for ever page load. I have been researching ways to speed up the
page and was hoping someone might point me in the right direction. Are
there any guidelines anywhere control usage and how many you should try to
limit to or what to do if you really need this many controls on one page.
One thing I was wondering about was if I break the page up into multiple web
user controls, ascx pages, and then use them in my main page, will that
truly help performance. In general there are any number of combination of
the controls that are visible or not, probably at most only about 10-20% of
the total count are ever visible at once, but its always a different
combination. By moving groups of controls into web user controls, will all
of the ones moved to the web user control get processed with ever page load
if the whole web user control is not visible? Or is there some way to
control whether they would get processed or not. Any help is appreciated.

TIA.

==============
Joe Reazor
Gorbel Inc.
email: joereaATgorbelDOTcom

 

[Cowboy (Gregory A. Beamer) - MVP]

If many of the controls are not visible at a particular time, I would
consider turning off ViewState. If you need the values, you will have to
cache between hits and control the repopulation of these controls. It is
likely the ViewState is killing you.

Personally, I would re-examine the page and determine if there is any way to
re-architect with some form of temporary persistent storage for the data in
question (when the controls are invisible). With 1440 controls, ViewState
will kill you.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[John Saunders]

I've got an asp.net page that has approximately 1,440 controls on it. You
must think I'm crazy, but we need to have the page organized in this
fashion. As you can imagine, the page takes a very long to to process, on
the order of 20-30 seconds, even though only a small number of the
controls
are generally visible at once it still has to process all the controls on
the page for ever page load.

What do you mean "it has to process all the controls"? What kind of
processing does it have to do on invisible controls? When you set
Visible=false, the controls don't render as HTML at all.

I have been researching ways to speed up the
page and was hoping someone might point me in the right direction. Are
there any guidelines anywhere control usage and how many you should try to
limit to or what to do if you really need this many controls on one page.
One thing I was wondering about was if I break the page up into multiple
web
user controls, ascx pages, and then use them in my main page, will that
truly help performance.

It would also help if you could break the page up into sets of controls and
put each set in its own Panel control. Hide an entire set by making
Panel.Visible = false. This will likely be faster than .ascx files,
especially since you'd have to go create the .ascx files. But you can just
go in and surround sets of controls with <aspanel> ... </aspanel>.


Also, if this doesn't speed things up enough, I recommend you look into the
"processing time" more deeply. For instance, how does this page perform if
you remove all of the business logic? What if you remove everything but the
controls themselves? Does it still take 20 seconds to process?

John Saunders

 

[Joe Reazor]

I already have everything organized on panels and control the visibility of
the panels. Unless my understanding is wrong, visiblity is just a "last
step" that really only affects the actual rendering of the controls. All of
the processing that goes on to populate the controls, still happens. Meaning
that each control has to be created using all the attributes as declared and
then my business logic that affects the control also executes. Visibility
gets processed just like any other property and then in the rendering step
it just doesn't render, but the entire control is still "processed" just as
if it were visible.. But maybe I am wrong. Is the runtime smart enough to
look at visibility first and if false don't do anything else with that given
control? It would be nice, but I doubt it.


==============
Joe Reazor
Gorbel Inc.
email: joereaATgorbelDOTcom

 

[John Saunders]

I already have everything organized on panels and control the visibility of
the panels. Unless my understanding is wrong, visiblity is just a "last
step" that really only affects the actual rendering of the controls. All
of
the processing that goes on to populate the controls, still happens.
Meaning
that each control has to be created using all the attributes as declared
and
then my business logic that affects the control also executes. Visibility
gets processed just like any other property and then in the rendering step
it just doesn't render, but the entire control is still "processed" just
as
if it were visible.. But maybe I am wrong. Is the runtime smart enough
to
look at visibility first and if false don't do anything else with that
given
control? It would be nice, but I doubt it.

One example: since an invisible control didn't render, it doesn't post back.

Also, if your panels represent subsets of your application as well as
subsets of your form, then the decision to make a panel invisible should
equate to a decision to not process that subset of your application. The
controls on an invisible panel shouldn't be getting populated at all.

Since you've already got the controls on panels, maybe it would make sense
to yank out each panel+controls into a .ascx page. This would also be a
good opportunity to move the code which referenced those controls and panel
to the .ascx page. You could then have the .ascx expose a Visible property,
and decide not to perform any of the processing if Visible is false.


John Saunders

 

[bruce barker]

asp.net has too many nested processing loops to support this many controls
on a page, and falls apart in the hundreds of controls, much less thousands.

you should switch to dynamic control, and only create the ones you need. if
they are sets of panels, create a seperate control for each panel, then
create the panels need, rather than set visiblility. store in view state a
simple list of the panels, so you know which ones to render in the postback.

-- bruce (sqlwork.com)


| I've got an asp.net page that has approximately 1,440 controls on it. You
| must think I'm crazy, but we need to have the page organized in this
| fashion. As you can imagine, the page takes a very long to to process, on
| the order of 20-30 seconds, even though only a small number of the
controls
| are generally visible at once it still has to process all the controls on
| the page for ever page load. I have been researching ways to speed up the
| page and was hoping someone might point me in the right direction. Are
| there any guidelines anywhere control usage and how many you should try to
| limit to or what to do if you really need this many controls on one page.
| One thing I was wondering about was if I break the page up into multiple
web
| user controls, ascx pages, and then use them in my main page, will that
| truly help performance. In general there are any number of combination of
| the controls that are visible or not, probably at most only about 10-20%
of
| the total count are ever visible at once, but its always a different
| combination. By moving groups of controls into web user controls, will
all
| of the ones moved to the web user control get processed with ever page
load
| if the whole web user control is not visible? Or is there some way to
| control whether they would get processed or not. Any help is appreciated.
|
| TIA.
|
| ==============
| Joe Reazor
| Gorbel Inc.
| email: joereaATgorbelDOTcom
|
|