Mehul,
in this post,
described some of the results of the efforts we've been putting into
optimizing our ASPxGridView and other miscellaneous ASP.NET controls
in order to keep our pole position for having the speediest ASP.NET
controls out there.
Although "Performance is Everything" is a fun slogan, and overall
speed improvements like these are very important, in reality raw
performance isn't really the whole enchilada. With such speed comes
great responsibility. Not yours, you understand, but ours.
There's a truism in computer programming (and being that we're talking about computers, it's not universally true, but never mind) that many discover for
themselves or have shown to them: to get greater speed you have to use
more memory. Think of, for example, storing a table of pre-computed
results for some calculation you do. If the result of the calculation
is there in the table, use it, otherwise calculate the value from
scratch and store it in the table. (The example I'm thinking of here,
as it my algorithmic wont, is calculating a CRC value.)
So, did we, in our quest for more speed, just allocate a whole chunk
of memory on the server and on the client and pre-compute some values?
Are we in your web server storing huge data structures in your session
variable? Are we in your client futzing with your DOM? Are we in your browser's Javascript interpreter chewing it up and spitting it out? Are you or your
server going to start sweating as soon as more than 10 people use your
web application and page thrashing occurs?
This is where the responsibility factor comes in. No, we didn't go for
the "more memory == more speed" easy answer. Instead, we thought hard about
the path that data has to take from data store to the user's browser,
we took a good hard look at the design of our class model, we
dissected how that class model renders HTML and how the browsers show
the result. We also stepped back and looked at how to better integrate
AJAX to help make the control seem more performant by doing extra work
in the background. The overall result was as Mehul described it: a 2.5 times speed increase on average.
The data path is an easy one to consider, since most issues seem to
flow from it. The less data you have to chuck around to get things
done, the faster things will be, especially in a web application where
there are several different segments to the path (database to web
server via the LAN, web server to browser program via the Internet,
browser to the screen via the DOM). I'm not just talking about data
from the database either: the amount and complexity of HTML and
Javascript also stresses a data path (the data path from the web
server to your browser and thence through the DOM parser).
Mehul, yesterday, talked about optimizing the grid and miscellaneous
controls. Tomorrow, I'll talk about another optimization we made to
help make the ASPxScheduler more performant.