Online Book Reader

AJAX In Action [146]

Again, we have a hyperlink to invoke both the fast and the slow function, using the value in an HTML form field as the argument. In this case, it specifies how many little DOM nodes to add to the container. We found 640 to be a reasonable value. The results of a simple test are presented in table 8.2.

Licensed to jonathan zheng

296

CHAPTER 8

Performance

Table 8.2 Profiling results for DOM node creation

Algorithm

Number of Page Layouts

Execution Time (ms)

Original

641

681

Optimized

1

461

Again, the optimization based on received wisdom does make a difference. With our profiler, we can see how much of a difference it is making. In this particular case, we took almost one third off the execution time. In a different layout, with different types of nodes, the numbers may differ. (Note that our example used only absolutely positioned nodes, which require less work by the layout engine.) The profiler is easy to insert into your code, in order to find out. Our final example looks at a JavaScript language feature and undertakes a comparison between different subsystems to find the bottleneck.

Minimizing dot notation

In JavaScript, as with many languages, we can refer to variables deep in a complex hierarchy of objects by “joining the dots.” For example: myGrandFather.clock.hands.minute

refers to the minute hand of my grandfather’s clock. Let’s say we want to refer to all three hands on the clock. We could write

var hourHand=myGrandFather.clock.hands.hour;

var minuteHand=myGrandFather.clock.hands.minute;

var secondHand=myGrandFather.clock.hands.second;

Every time the interpreter encounters a dot character, it will look up the child variable against the parent. In total here, we have made nine such lookups, many of which are repeats. Let’s rewrite the example:

var hands=myGrandFather.clock.hands;

var hourHand=hands.hour;

var minuteHand=hands.minute;

var secondHand=hands.second;

Now we have only five lookups being made, saving the interpreter from a bit of repetitive work. In a compiled language such as Java or C#, the compiler will often optimize these repetitions automatically for us. I don’t know whether JavaScript interpreters can do this (and on which browsers), but I can use the stopwatch library to find out if I ought to be worrying about it. Licensed to jonathan zheng

JavaScript execution speed

297

The example program for this section computes the gravitational attraction between two bodies, called earth and moon. Each body is assigned a number of physical properties such as mass, position, velocity, and acceleration, from which the gravitational forces can be calculated. To give our dot notation a good testing, these properties are stored as a complex object graph, like so:

var earth={

physics:{

mass:10,

pos:{ x:250,y:250 },

vel:{ x:0, y:0 },

acc:{ x:0, y:0 }

}

};

The top-level object, physics, is arguably unnecessary, but it will serve to increase the number of dots to resolve.

The application runs in two stages. First, it computes a simulation for a given number of timesteps, calculating distances, gravitational forces, accelerations, and other such things that we haven’t looked at since high school. It stores the position data at each timestep in an array, along with a running estimate of the minimum and maximum positions of either body.

In the second phase, we use this data to plot the trajectories of the two bodies using DOM nodes, taking the minimum and maximum data to scale the canvas appropriately. In a real application, it would probably be more common to plot the data as the simulation progresses, but I’ve separated the two here to allow the calculation phase and rendering phase to be profiled separately.

Once again, we define two versions of the code, an inefficient one and an optimized