Memory leak patterns in JavaScript

Memory leaks linkdump Page last changed today Since the comments to my previous posts contain a few useful links to memory leaks and closure resources, I thought I'd create a linkdump for future reference. Note that I only included those articles that explain what they're doing and why and give code examples. I ignored the pages that just throw scripts over the fence and leave it to the reader to figure out what they're all about. Let's start with the horse's mouth: over on MSDN IE developer Justin Rodgers explains the fundamental problems. On jibbering.com Richard Cornford gives a fundamental overview of JavaScript closures. Mihai Bazon also has a good article on memory leaks and closures, and he treats several real-world event handling examples. In reaction to my tests, Laurens van den Oever gives some more insight in my test script 5, and how to change it so that it leaks memory. If you know of more resources, please add a comment. Comments are closed.

Javascript Closures Introduction Closure A "closure" is an expression (typically a function) that can have free variables together with an environment that binds those variables (that "closes" the expression). Closures are one of the most powerful features of ECMAScript (javascript) but they cannot be property exploited without understanding them. They are, however, relatively easy to create, even accidentally, and their creation has potentially harmful consequences, particularly in some relatively common web browser environments. To avoid accidentally encountering the drawbacks and to take advantage of the benefits they offer it is necessary to understand their mechanism. The simple explanation of a Closure is that ECMAScript allows inner functions; function definitions and function expressions that are inside the function bodes of other functions. Unfortunately, properly understanding closures requires an understanding of the mechanism behind them, and quite a bit of technical detail. Assignment of Values

addEvent() – Follow Up This is a follow-up to my addEvent solution. From the comments to that post it is clear that there were a couple of things missing. The first was the ability to return a value from the handleEvent function. The second was the ability to use W3C standard methods to cancel the event and stop event propagation (event bubbling). Below are the amendments necessary: function handleEvent(event) { var returnValue = true; event = event || fixEvent(window.event); var handlers = this.events[event.type]; for (var i in handlers) { this. One other issue, pointed out by PPK (via email).

Memory Leakage in Internet Explorer - revisited Introduction If you are developing client-side re-usable scripting objects, sooner or later you will find yourself spotting out memory leaks. Chances are that your browser will suck memory like a sponge and you will hardly be able to find a reason why your lovely DHTML navigation's responsiveness decreases severely after visiting a couple of pages within your site. A Microsoft developer Justing Rogers has described IE leak patterns in his excellent article. In this article, we will review those patterns from a slightly different perspective and support it with diagrams and memory utilization graphs. Why does the memory leak? The problem of memory leakage is not just limited to Internet Explorer. Don't get me wrong. Each browser has its own strengths and weaknesses. If you have read my previous article, then you already know that I am a usability, accessibility and standards crack. A simple beginning Let us begin with a simple example: Increasing the frequency No visible leak huh? Conclusion