Designing for performance	311

this.front.backingObj=this;

}

MyObject is a user-defined type. Every instance will refer to a DOM node as this.front, and the DOM node will refer back to the JavaScript object as this.backingObj.

To remove this circular reference while finalizing the object, we might offer a method such as this:

MyObject.prototype.finalize=function(){

this.front.backingObj=null;

this.front=null;

}

By setting both references to null, we break the circular reference.

Alternatively, a DOM tree could be cleaned up in a generic fashion, by walking the DOM tree and eliminating references on the basis of name, type, or whatever. Richard Cornford has suggested such a function, specifically for dealing with event handler functions attached to DOM elements (see the Resources section at the end of this chapter).

My feeling is that generic approaches such as this should be used only as a last resort, as they may scale poorly to the large document trees typified by Ajax rich clients. A structured pattern-based approach to the codebase should enable the programmer to keep track of the specific cases where cleanup is required.

A second point worth noting for IE is that a top-level “undocumented” function called CollectGarbage() is available. Under IE v6, this function exists and can be called but seems to be an empty stub. We have never seen it make a difference to reported memory in the Task Manager.

Now that we understand the issues of memory management, let’s explore the practicalities of measuring it and applying those measurements to a reallife application.

8.4 Designing for performance

We stated at the outset that performance consisted of both good execution speed and a controllable memory footprint. We also said that design patterns could help us to achieve these goals.

In this section, we’ll see how to measure memory footprint in real applications, and we’ll use a simple example to show how the use of design patterns can help us to understand the fluctuations in memory footprint that we may see in working code.

312CHAPTER 8

Performance

8.4.1Measuring memory footprint

When we measured execution speed, we could do so either in JavaScript code using the Date object or with an external tool. JavaScript doesn’t provide any built-in capabilities to read system memory usage, so we’re dependent on external tools. Fortunately, we have several to choose from.

There are a variety of ways to see how much memory your browser is consuming during execution of your application. The simplest way to do so is to use a system utility appropriate to your operating system to see the underlying processes. On Windows systems, there is the Task Manager, and UNIX systems have the con- sole-based top command. Let’s look at each of these in turn.

Windows Task Manager

The Windows Task Manager (figure 8.5) is available on many versions of Windows (Windows 95 and 98 users are out of luck here). It provides a view of all processes running in the operating system and their resource use. It can usually be invoked

Figure 8.5 Windows Task Manager showing running processes and their memory usage. Processes are being sorted by memory usage, in descending order.

Designing for performance	313

from the menu presented to the user when she presses the Ctrl+Alt+Delete key combination. The Task Manager interface has several tabs. We are interested in the tab labeled Processes.

The highlighted row shows that Firefox is currently using around 38MB of memory on our machine. In its default state, the Mem Usage column provides information on active memory usage by the application. On some versions of Windows, the user can add extra columns using the View > Select Columns menu (figure 8.6).

Showing the Virtual Memory Size of a process as well as Memory Usage can be useful. Memory Usage represents active memory assigned to an application, whereas Virtual Memory Size represents inactive memory that has been written to the swap partition or file. When a Windows application is minimized, the Mem Usage will typically drop considerably, but VM Size will stay more or less flat,

Figure 8.6 Selecting additional columns to view in the Task Manager’s Processes tab. Virtual Memory Size shows the total amount of memory allocated to the process.

314CHAPTER 8

Performance

indicating that the application still has an option to consume real system resources in the future.

UNIX top

A console-based application for UNIX systems (including Mac OS X), top shows a very similar view of processes to the Windows Task Manager (figure 8.7).

As with Task Manager, each line represents an active process, with columns showing memory and CPU usage and other statistics. The top application is driven by keyboard commands, which are documented in the man or info pages and on the Internet. Space precludes a fuller tutorial on top here, or an exploration of the GUI equivalents such as the GNOME System Manager that may be present on some UNIX/Linux systems.

Power tools

Beyond these basic tools, various “power tools” are available for tracking memory usage, offering finer-grained views of the operating system’s internal state. We can’t do justice to the full range of these tools, but here are brief pointers to a couple of freeware tools that we have found useful.

Figure 8.7 UNIX top command running inside a console, showing memory and CPU usage by process.

Designing for performance	315

First, Sysinternal.com’s Process Explorer tool (figure 8.8) is perhaps best described as a “task manager on steroids.” It fulfills the same role as Task Manager but allows for detailed drilldown into the memory footprint and processor use of individual processes, allowing us to target Internet Explorer or Firefox specifically.

Second, J. G. Webber has developed Drip (see the Resources section), a simple but powerful memory management reporter for Internet Explorer that directly queries an embedded web browser about its known DOM nodes, including those that are no longer attached to the document tree (figure 8.9).

However, even with the basic tools, we can discover a lot about the state of a running Ajax application.

Figure 8.8 Process Explorer provides detailed reporting on memory and processor usage on a per-process basis, allowing for more accurate tracking of the browser’s footprint on a Windows machine. This window is tracking an instance of Mozilla Firefox running the stress test described in section 8.4.2.