Thursday, December 1st, 2005

Tuning Ajax

Category: Articles

Dave Johnson has written a piece on Tuning Ajax.

Unless you live under a rock, you’ve heard about and likely even used AJAX. Asynchronous JavaScript and XML is becoming an increasingly pervasive deployment methodology, which necessitates that people start to both understand how it works and actually consider it more seriously as an enterprise-level development tool. To that end, I will try to illustrate one method of benchmarking your AJAX applications as well as point out some of the major performance pitfalls I have encountered while developing AJAX components and applications.

The article starts with basic benchmarking:

// global variables
var g_time = [];
var g_iteration = 0;
var g_maxIterations = 0;

function DoTest() {
  var start = new Date().getTime();
  //    do stuff here.
  var end = new Date().getTime();
  //    save time
  g_time.push(end - start);
  if (g_iteration > g_maxIterations)
      return;
  g_iteration++;
  setTimeout(DoTest);
}

He then delves into using JavaScript in a JavaScript-y way (not sure what this had to do with performance…), XML, XSLT, JSON, DOM and CSS, and finally concludes:

In AJAX applications, performance is undoubtedly important. Even so, as with any engineering discipline there are compromises to be made. End users will have different operating systems and browsers, applications will have various amounts of code or data to download and process, and there will be different business problems that AJAX can help solve. You need to consider the OS/browser statistics of the target user, and design with performance on those systems in mind. Also, both code and data size have a large effect not only on processing time but also on network latency, which has led to important AJAX design patterns such as pre-fetching of data. The bottom line is that in a commercial environment it is always prudent to let your end users and the business case for your AJAX application direct your choices. Whether you are a single person building an open source AJAX combo box or a small company trying to compete with large AJAX vendors, you need to consider who the end users are and how they use the product.

Writing fast JavaScript isn’t always obvious. There are few steadfast rules, and developers need to be vigilant in their performance benchmarking as well as in how they write code. I like to think writing enterprise AJAX applications is a lot like writing assembly code for a real-time system; to make it fast you generally have to step outside of the OOP best practices paradigm and do what works, not what makes your code easy to read and maintain. This flies in the face of some primary virtues of software engineering. Eventually these techniques will mature and become encapsulated in server-side logic and declarative markup where they can be better managed and leveraged. Until then, we’ll have to keep on finding new and faster ways of tuning AJAX.

Posted by Dion Almaer at 9:27 am
1 Comment

+++--
3.8 rating from 10 votes

1 Comment »

Comments feed

Hey Dion, the JavaScript-y stuff was just about how you create JavaScript objects and access properties of objects.

Instantiating objects using a “traditional” approach such as:
var Foo = new Object();
Foo.a = “100”;
Foo.b = “200”;
is considerably slower than doing it this way:
Foo = {
a: “100”,
b: “200”
}

Similarly, when you are accessing those properties (a and b) you should not do it using the dot notation:
alert(Foo.a);
but instead use the associative array method:
alert(Foo[‘a’]);

thanks for the post :)
– dave

Comment by Dave Johnson — December 19, 2005

Leave a comment

You must be logged in to post a comment.