With speed comes responsibility

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.

Free DevExpress Products - Get Your Copy Today