Don't Let Memory Leaks Reduce Your Ajax Application Efficiency
Developers are turning to Ajax as a foundation for web application design for a number of reasons, but one of the most important is efficiency. The gains Ajax enables in client-server interaction just can't be overstated.
It makes no sense at all to work with Ajax, and then lose all the efficiency you've gained by letting memory leaks corrupt your application's performance. If you're using Ajax, don't slack off in your attention to memory management.
Not all of us use the term "memory leak," which is somewhat misleading, so let me clarify: when developers say "memory leak," they're talking about memory that an application has made use of, then failed to release, thereby reducing the available resource.
Ajax's Special Memory Management Considerations
Probably the most unusual piece of AJAX is the Document Object Model. Within AJAX and beyond, DOM is growing in popularity, but few developers really think about its memory management considerations. To do so effectively, it's important to understand DOM's position in the Ajax framework.
Remember that Ajax adheres to the MVC model - Model, View, Controller - and that the interaction between these 'layers' of an application is very explicitly defined. Within this framework, the MVC model plays out this way:
- The View is populated (prominently but not exclusively) by DOM nodes
- The Controller is where the two interact
Here, memory management considerations happen in this third layer. In oversimplified terms, the Model layer and View layer are mutually referential, and the developer must sometimes manage the terminations of these references. In what cases would this be necessary?
It's important to note that any DOM element may be referenced via the document it is part of, even if there is no programmatic reference to it. How, then, would you deallocate the memory held by the button, if you wanted to be rid of it? It would not be enough to break the reference between the button and the DOM element. By nulling the button; the memory allocated to the button would remain taken. The reference must be broken in the other direction: null the DOM element, and null the button reference, as well.
Don't Rely on Garbage Collection
What's actually happening is that the garbage collector is tracking how variables are being used. If a variable can be immediately referenced, it is left as-is; if it can't be, it is not considered necessary any longer and the memory it is using is tagged as available. The garbage collection process periodically 'purges,' releasing the tagged memory for use.
Here's an example. An object modeler might create an object Parent, and give Child to Parent, such that methods exist to add Child and remove Child from Parent. Once added, Child can be accessed as long as Parent can be accessed; if Parent ceases to be accessible, so do all instances of Child. At this level, it's simple and functional and nothing will go wrong.
But developers can, and often do, complicate such relationships: you can instantiate Child repeatedly under Parent and build backward references to Parent into our Child interface, as when Child is our object of interest and Parent is explicitly referenced in the interface. Developers are (perhaps unfortunately) free to use that explicit reference or not. You can null the Parent instance, and all Child instances that do not explicitly reference Parent are likewise nulled. However, if you explicitly reference Parent through one or more instances of Child, then nulling Parent does you no good; the memory allocated to Parent is untouchable, as long as one reference path through a Child exists. Only through actively nulling every instance of Child does Parent get deallocated.
Watch for these possibilities in your object modeling or your use of previously written objects. Carefully study the possible paths-of-reference, and if you need to actively release memory, by all means, do it! Otherwise you're spinning your wheels working in Ajax to begin with.
About the Author
Scott Robinson is an IT consultant to the U.S. manufacturing, brokerage, healthcare, and biotech industries. He has managed design teams sponsored by the Department of Defense and the Department of Energy, and has worked with academic research groups. He is vice president of development at Quantumetrics, Inc.