AJAX In Action [157]
8.4.3 Results: how to reduce memory footprint 150-fold
Running the stress test we just described under various combinations of patterns yielded radically different values of memory consumption, as reported by the Windows Task Manager. These are summarized in table 8.4.
Table 8.4 Benchmark results for ClickBox example code
ID
Reuse DOM Nodes
Unlink On Hide
Break Cyclic Refs
Final Memory Use (IE)
A
N
N
N
166MB
B
N
N
Y
84.5MB
C
N
Y
N
428MB
D
Y
N
N
14.9MB
E
Y
N
Y
14.6MB
continued on next page
Licensed to jonathan zheng 322 CHAPTER 8 Performance Table 8.4 Benchmark results for ClickBox example code (continued) ID Reuse DOM Nodes Unlink On Hide Break Cyclic Refs Final Memory Use (IE) F Y Y N 574MB G Y Y Y 14.2MB The results in table 8.4 were recorded for the stress test on a fairly unremarkable workstation (2.8GHz processor, 1GB of RAM) for Internet Explorer v6 on Windows 2000 Workstation under various permutations of patterns. Initial memory use was approximately 11.5MB in all cases. All memory uses reported are the Mem Usage column of the Processes tab of the Task Manager application (see section 8.4.1). Since we’re confronting real numbers for the first time, the first thing to note is that the application consumes quite a bit of memory. Ajax is often described as a thin client solution, but an Ajax app is capable of hogging a lot of memory if we make the right combination of coding mistakes! The second important point about the results is that the choice of design patterns has a drastic effect on memory. Let’s look at the results in detail. Three of our combinations consume less than 15MB of RAM after rendering and unrendering all the ClickBox widgets. The remaining combinations climb upward through 80MB, 160MB, to a staggering 430MB and 580MB at the top end. Given that the browser was consuming 11.5MB of memory, the size of additional memory consumed has varied from 3.5MB to 570MB—that’s a difference of over 150 times, simply by modifying the combination of design patterns that we used. It’s remarkable that the browser continued to function at all with this amount of memory leaking from it. No particular pattern can be identified as the culprit. The interaction between design patterns is quite complex. Comparing runs A, D, and F, for example, switching on the Reuse DOM pattern resulted in a huge decrease in memory usage (over 90 percent), but switching on Unlink On Hide at the same time generated a threefold increase! In this particular case, the reason is understandable—because the DOM nodes have been unlinked, they can’t be found by a call to document.getElementById() in order to be reused. Similarly, switching on Unlink On Hide by itself increased memory usage against the base case (comparing runs C to A). Before we discount Unlink On Hide as a memory hog, look at runs E and G—in the right context, it does make a small positive difference. Interestingly, there is no single clear winner, with three quite different combinations all resulting in only a small increase in memory. All three of these reuse Licensed to jonathan zheng Summary 323 DOM nodes, but so does the combination that results in the highest memory increase. We can’t draw a simple conclusion from this exercise, but we can identify sets