• Choose a category
• All
• Classic-Fiction

319

The debug panel on the right reports on the internal state of the system after various user events, such as adding or removing widgets from the container. The code has been written to allow us to swap in different patterns for creation and destruction of DOM elements and cyclic references while the application is running. The user may choose between these at runtime by checking and unchecking HTML form elements on the page. When the links that add or remove boxes from the container are activated, the combination of patterns that is used to implement the user interface will match the state of the checkboxes. Let’s examine each of these options and the corresponding code.

Reuse DOM Nodes checkbox

Checking this option will determine whether the ClickBox widget will try to find an existing DOM node when creating itself and create a new one only as a last resort. This allows the application to switch between the Create Always and Create If Not Exists patterns that we discussed in section 8.3.2. The modified rendering code follows: ClickBox.prototype.render=function(){

this.body=null;

if (reuseDOM){

this.body=document.getElementById(this.id);

}

if (this.body==null){

this.body=document.createElement("div");

this.body.id=this.id;

newDOMs++;

}else{

reusedDOMs++;

}

this.body.backingObj=this;

this.body.className='box1';

this.body.style.left=this.x+"px";

this.body.style.top=this.y+"px";

this.body.onclick=function(){

var clickbox=this.backingObj;

clickbox.incrementState();

}

}

Unlink On Hide checkbox

When a ClickBox is removed from the container (either by a second click or by calling Container.clear()), this switch will determine whether it uses the Remove By Hiding or Remove By Detachment pattern (see section 8.3.2):

ClickBox.prototype.hide=function(){

var bod=this.body;

Licensed to jonathan zheng

320

CHAPTER 8

Performance

bod.className='box3';

if (unlinkOnHide){

bod.parentNode.removeChild(bod);

}

...

}

Break Cyclic References checkbox

When removing a ClickBox widget, this toggle determines whether the references between the DOM element and the backing object are reset to null or not, using the Break Cyclic References pattern in an attempt to appease the Internet Explorer garbage collector:

ClickBox.prototype.hide=function(){

var bod=this.body;

bod.className='box3';

if (unlinkOnHide){

bod.parentNode.removeChild(bod);

}

if (breakCyclics){

bod.backingObj=null;

this.body=null;

}

}

Form controls allow the user to add ClickBoxes to the container and to clear the container. The application may be driven manually, but for the purposes of gathering results here, we have also written a stress-testing function that simulates several manual actions. This function runs an automatic sequence of actions, in which the following sequence is repeated 240 times:

1

Add 100 widgets to the container, using the populate() function.

2

Add another 100 widgets.

3

Clear the container.

The code for the stressTest function is provided here:

function stressTest(){

for (var i=0;i<240;i++){

populate (100);

populate(100);

container.clear();

}

alert("done");

}

Licensed to jonathan zheng

Designing for performance

321

Note that the functionality being tested here relates to the addition and removal of nodes from the container element, not to the behavior of individual ClickBoxes when clicked. This test is deliberately simple. We encourage you to develop similar stress tests for your own applications, if only to allow you to see whether memory usage goes up or down when changes are made. Designing the test script will be an art in itself, requiring an understanding of typical usage patterns and possibly of more than one type of usage pattern.

Running the stress test takes over a minute, during which time the browser doesn’t respond to user input. If the number of iterations is increased, the browser may crash. If too few iterations are employed, the change in memory footprint may not be noticeable. We found 240 iterations to be a suitable