WebReference.com - Part 1 of Chapter 21: Professional JavaScript, from Wrox Press Ltd (6/6) | WebReference

WebReference.com - Part 1 of Chapter 21: Professional JavaScript, from Wrox Press Ltd (6/6)

To page 1To page 2To page 3To page 4To page 5current page

Professional JavaScript 2nd Edition

Issues Regarding Screen Updates

During the development of the ticker algorithm, some important pitfalls were found. These were especially problematic with the IE browser on the Macintosh.

Initially, the headline item was composed simply of the text that was visible. This meant that the clickable text in the A tag did not cover the entire frame. It was constantly being replaced to create the animated effect, therefore there was some degree of object construction and destruction going on.

If at the same time the mouse was being rolled over the headline, an event was being generated to indicate mouseOver. This edge detection is fine, as long as the objects being monitored are static and non-moving. Destroying the object that the mouse has just entered, even though another is created, causes some problems to the event handling mechanism, which has some kind of memory handle on the object that was originally rolled over.

Since that object no longer exists, the browser rapidly becomes very confused when the mouseOver event is handled. IE on the Macintosh simply cannot cope with this and the whole thing crashes catastrophically.

The same object boundary problems with mouseOver events were in evidence when the text string "LATEST:" was placed in front of the link but outside the A tag. This is why a background graphic containing that text is placed in the BODY tag. Some leading non-breaking spaces are used to indent the text in the anchor but are included inside the A tag. Some additional trailing non-breaking spaces are also included in the A tag to ensure the clickable object covers the entire area of the frame. Even so, word wrapping comes into play and there is some uncertainty about the right hand edge of the object, though this does not seem to cause as much of a problem.

Memory Leaks and Garbage Collection

In the early trials, a great deal of string concatenation and construction/destruction took place. The visible string was assembled one character at a time on each cycle of the ticker loop. Amazingly, this could consume 50K of memory every few seconds and before long, massive amounts of memory were being used up. This is because JavaScript does not properly clean up its 'Auto Release Pool' until the page is reloaded.

The final version of the ticker uses the sub-stringing capabilities of JavaScript to slice out an increasingly longer portion of the text string and performs no persistent string concatenation. There is evidence on some platforms that a very small memory leak may occur, which is much better than the original version. It would be nice to eliminate these leaks altogether. By way of illustration, the following approach leaks massively:

myString = "";
for(iii=0; iii<10; iii++)
   myString = myString + "A";

By contrast, this approach leaks hardly at all, although it appears to waste space by assigning content to myString at the outset:

myString = "AAAAAAAAAA";
for(iii=0; iii<10; iii++)

Every few minutes, the whole ticker page can be reloaded to avoid any small memory leaks becoming a problem. This was originally done within the JavaScript code based on a count of the number of headlines that had been played out. That has now been removed, and happens courtesy of the main page being reloaded by the browser.

This reloading also has the added benefit that the ticker headline list is likely to be refreshed very soon after the master copy on the web server has been updated. It isn't a perfect synchronization but it's good enough. Usage patterns from the web server logs indicate that people don't stay on the front page for very long before going to read a story and then coming back again. If they do leave the page on display for long periods, then an automated page refresh ensures the ticker is updated periodically. There is a trade off in setting the update period too short. If many hundreds of thousands of users have the front page on display with the ticker, shortening the update time causes a measurable increase in traffic and web server loading.

These memory-leaking problems were observed to be far worse on Windows than on the Macintosh version of IE. This may be due to a variety of reasons dependant on how the underlying memory management is implemented. The Macintosh system software is known to implement a particularly effective garbage collection and memory compacting scheme. Segments of memory within the application heap are moved when necessary to collect all the free space into one contiguous block. While this happens, the memory manager also frees up any purgeable space to keep things neat and tidy.

To page 1To page 2To page 3To page 4To page 5current page

Created: November 5, 2001
Revised: November 5, 2001

URL: http://webreference.com/programming/javascript/professional/chap21/1/6.html