• Choose a category
• All
• Classic-Fiction

showOrbit(count,isFast);

}

}

Licensed to jonathan zheng

JavaScript execution speed

301

The structure should be broadly familiar by now. The functions slowData() d and fastData() e contain the two versions of our calculation phase, which generates the data structures b. I’ve omitted the full algorithms from the listing here, as they take up a lot of space. The differences in style are described in the snippets we presented earlier and the full listings are available in the downloadable sample code that accompanies the book. Each calculation function has a stopWatch object assigned to it, profiling the entire calculation step. These functions are called by the showOrbit() function, which takes the data and then creates a DOM representation of the calculated trajectories c. This has also been profiled by a third stopwatch.

The user interface elements are the same as for the previous two examples, with hyperlinks to run the fast and the slow calculations, passing in the text input box value as a parameter. In this case, it indicates the number of timesteps for which to run the simulation. A third hyperlink displays the profile data. Table 8.3

shows the results from a simple run of the default 640 iterations.

Table 8.3 Profiling results for variable resolution

Algorithm

Execution Time (ms)

Original calculation

94

Optimized calculation

57

Rendering (average)

702

Once again, we can see that the optimizations yield a significant increase, knocking more than one-third from the execution time. We can conclude that the folk wisdom regarding variable resolution and the use of too many dots is correct. It’s reassuring to have checked it out for ourselves.

However, when we look at the entire pipeline of calculation and rendering, the optimization takes 760 ms, as opposed to the original’s 796 ms—a savings closer to 5 percent than 40 percent. The rendering subsystem, not the calculation subsystem, is the bottleneck in the application, and we can conclude that, in this case, optimizing the calculation code is not going to yield great returns. This demonstrates the broader value of profiling your code. It is one thing to know that a piece of code can be optimized in a particular way and another to Licensed to jonathan zheng

302

CHAPTER 8

Performance

know what the expected returns of such an operation would be. It might be tempting to conclude that DOM operations are roughly eight times more costly than pure JavaScript calculations, but that holds true only for this specific example. You may well find that to be the case in many situations, but a rule of thumb is best supplemented by a few measurements—and preferably on a range of different machines and browsers. We won’t spend more time now on profiling and execution speed. The examples that we have run through should give you a feel for the benefits that profiling can provide on your Ajax projects. Let’s assume that your code is running at a satisfactory speed thanks to a bit of profiling. To ensure adequate performance, you still need to look at the amount of memory that your application is using. We’ll explore memory footprints in the next section.

8.3 JavaScript memory footprint

The purpose of this section is to introduce the topic of memory management in Ajax programming. Some of the ideas are applicable to any programming language; others are peculiar to Ajax and even to specific web browsers. A running application is allocated memory by the operating system. Ideally, it will request enough to do its job efficiently, and then hand back what it doesn’t need. A poorly written application may either consume a lot of memory unnecessarily