[thelist] .NET: Generally speeding things up (Ajax?)

[Casey Crookston]

Anthony, this helps a ton.  Thank you.  Can I offer an examples for
learning purposes?

When the page first loads, there is an intial dropdown populated from
the database.  Based on the selection of this dropdown, a second
dropdown is populated from the database.  Based on this second
selection, 6 textboxes are populatted.  The user may now opt to leave
the text boxes as is, or make changes.

At this point, the user starts to add user-controls to the page.  This
user control is simple: it's an .ascx file which contains one dropdown
and two text boxes.  The user adds one control, makes changes to the
dropdown and two text boxes, then adds another. We don't know ahead of
time how many controls will be added.  Could be one.  Could be twenty.  

Side note: It took me a LONG LONG time (days) to figure out how to
alllow the user to keep adding controls and to maintain the previous
controls each time a new one is added.  I never did get it done on my
own, and I ended up using a little third-party .dll to get the job done.
I would still like a better solution.

Problem: The page works fine and is speedy enough up to the point where
the user starts adding the controls.  With each control that is added,
the entire page goes blank, and then re-builds slowly.

Ok - I just did something after typing all of this above.  I took your
advice and examined the ViewState string in the source code.  Before the
first user-control was added, I copied and pasted the string into Word.
It is about 5 lines long.  Then I added a control and did it again.  The
ViewState string is now 26 PAGES long.  Holy F!#g S!$##t !!  Imagine
after two, three, five, ten controls are added !!!!

It looks like I have identified the souce of the slowness.  So I am back
to my original problem: How do I EFFECTIVLY add multiple instances of
this user control, maintain them each, and not bloat the viewstate?

Like I said, I have been trying to solve this now for almost a week.  I
have posted in multiple forms, including this one, and have had zero
feedback.  Ug.

If anyone can help, I will UPS you case of malt beverage.  Serious.  For
real.

Casey


-----Original Message-----
From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On Behalf Of Anthony Baratta
Sent: Wednesday, April 18, 2007 11:42 AM
To: thelist at lists.evolt.org
Subject: Re: [thelist] .NET: Generally speeding things up (Ajax?)

You hit on what I consider the biggest weakness of the dotNet Framework,
the full dependency on post-backs for EVERYTHING. It just does not scale
well with complex forms.

One option is to move to AJAX calls, but then you are doing an end run
around the State Management that dotNet provides you. And therefore you
will be leaving behind some of the functionality that the controls give
you because they are heavily dependent upon the state management and
post-back for many of their "features".

First thing I would do is check how your page is built. You should only
be building your main controls ONCE when the page is originally built.
Then on each post back you should only be working with the changes
necessary to update your page and add new / take away controls - based
on user selections. Try and make use the State Manager as much as
possible so you are not recreating  and re-populating controls
unnecessarily with data with every post back.

How big is your viewstate when it's rendered as HTML? (The hidden form
element "_viewstate".) The size of that sucker can also be a drain on
rendering because it can get frigging huge! dotNet 2.0 is suppose to
keep that element on a diet - but sometimes it still can get out of
control. So, make sure you only use Web / HTML Control when it's
absolutely necessary. Don't make anything a control that you don't need
to manipulate server side. For example we generate HTML Data grids
server side and stuff them into Container DIVs, then send to the
browser. We always turn off ViewState for those controls because we
don't care about maintaining state for that control - it's display only
and when changed vis AJAX we don't want the server attempting to
recreate the original data stored in that container because it's mostly
likely changed with out the server knowing about it. So we take the very
very small performance hit and rebuild that Data grid (via it's DB
stored data) with each page load -
no matter what. But what that gives us is a smaller _viewstate - which
gives us a faster rendering speed on the browser side. (Robbing Peter to
pay Paul, but the server's grab and build of the data is much much
faster than the browser's grab and render when the browser has a large
viewstate to contend with.)

Now if your page is very "heavy" with HTML as a result, try and only
build build your dynamic controls when needed, versus hiding them on the
page some where - save on page weight.  Try and make sure your page
construction is as simple as possible to keep rendering time down to a
minimum. Don't over nest DIVs. Fix the width of everything.

These types of issues is exactly why I ditched the dotNet Web Controls
and only use the HTML Controls. And I use AJAX when I need the HTML
Element / HTML Control to talk to the server - never multiple post-backs
like the way dotNet wants you to. The only time my pages post back in
the dotNet way is for final submittal of the form. All other posts, when
necessary, are AJAX driven. Yes, this means I don't get full value of
the State Manager, but I get better response time and less hassle
because I'm more in control of the page - only updating targeted
sections with out a full page refresh. 

Hope that helps, your mileage may vary.