This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.

Tuning AJAX Applications for Performance
Performance can have different meanings, depending on your perspective. If you're the end user of an application, performance means that the application is responsive in all circumstances. If you're an application owner or product manager, performance may mean that the application is scalable, i.e., the number of servers you have is directly proportional to the number of users you can handle. In this chapter we're more concerned with the former kind of performance rather than the latter.

Optimization is most successful if it starts with good fundamentals. First, your application must use efficient algorithms. If your application doesn't use efficient algorithms to begin with, no amount of tweaking will improve its performance in a meaningful way. A good reference on this topic is Algorithms and Complexity by Herbert S. Wilf. Second, understanding the strengths and weaknesses of your platform - which operations or functions are slow and which ones are fast - is a necessary precondition for planning where to tune. Last, once we have efficient algorithms and knowledge of our platform, we can identify bottlenecks and hotspots where optimization techniques can effectively be brought to bear.

A Warning About Performance Tuning
One word of advice about performance tuning: avoid it if at all possible. Nothing is guaranteed to make your programs as hard to understand and maintain as optimization and performance tuning. The solutions to performance problems usually involve adding layers of complexity and changing your code in ways that have little to do with the underlying problem your application is trying to solve. So, if you have to tune performance, try to get away with as little of it as possible.

Another reason to avoid performance tuning is that the performance characteristics of the various browsers - Internet Explorer, Firefox, Opera, Safari - are different. Fixing performance problems in one platform may exacerbate the performance problems in another. If you're determined to support the same level of performance in the four major browser platforms, you have four times the work using different tools and techniques for each platform. The problem looks even worse once you consider the various major and minor versions of each browser platforms, each with their own issues and performance quirks. Performance tuning for a non-trivial AJAX application begins to look like a full-time job.

Still, some amount of performance tuning with AJAX applications is unavoidable. For one thing, these applications have a very different behavior than that of a typical Web application. In a typical Web application, Web pages are frequently reloaded, wiping out the memory for that page and starting with a clean slate. With AJAX applications, where a single page application may remain in the browser for hours, or even days in the case of a dashboard application, any problems with memory or other resource leaks are magnified. For another, AJAX allows you to make many small HTTP requests instead of one big post-back, and this brings with it its own set of problems. Frequent requests can stress back-end servers, load balancers, and firewalls, causing performance to degrade. Also, those frequent small requests can end up bumping up against browser limits or a sluggish network connection, creating bottlenecks.

In this chapter we'll explore some techniques and tools for solving the above performance issues. These solutions can be used alone or in combination. You will have to use your judgment to determine whether the tradeoff in complexity is worth the extra performance.

Measuring Performance
Performance tuning means measuring. Simply saying that your application "seems slow" is not useful. You have to know why it's slow, whether it's the slow response time of the back-end server, slow-rendering XHTML, a pokey inner loop, or some other cause that's making your application crawl. Once you've measured and identified the reason, you need to measure the effects of your tuning efforts. Just eyeballing it isn't enough. You need to know whether that tweak in cache headers or compression of your JavaScript made a difference and whether the small performance gain was really worth the extra complexity.

Note: Performance tests and measures can have uses beyond the tuning process. If you package your tests into a regression framework that can be run by support staff in response to reported application sluggishness, you have a good chance of quickly tracking down the source of the problem.

Timing Execution Speed
The simplest way to measure execution speed in JavaScript also happens to be the one way that's guaranteed to work in all browsers: using the getTime() method of the date object. This method returns the number of milliseconds that have passed since midnight of January 1, 1970. Milliseconds are thousands of a second, so you would divide by 1,000 to get the number of seconds since 1/1/1970. You can also do date arithmetic using this method call. For instance:

<html>
<head>
<title>Object Creation Test</title>
<script>
function benchmark(func) {
    var date = new Date();
    var start = date.getTime();
    // run func
    func();
    // end func
    date = new Date();
    var end = date.getTime();
    alert(end-start);
}
var testFunc = function() {
    for (var i = 0; i < 100000; i++) {
      var Obj = new Object();
    }
}
</script>
</head>
<body>
<input type="button" value="Run Test" onclick="benchmark(testFunc);"/>
</body>
</html>

Go ahead and load the above page into a couple of different browsers to see the difference in performance. Since the object creation statement won't take very much time, we've wrapped it in a loop so we can measure how long 100,000 of these operations will take. On a decent XP laptop, IE6 ran the example in an average of 1,200 milliseconds, Firefox 1.5 ran it in 500 milliseconds, and Opera ran it in 250 milliseconds. That's not to say that IE6 will always be slower than Firefox or Opera. Rather, you need to be aware that different browsers have different performance characteristics.

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.