From what I recall of a not too distant past, Javascript interpreters suffered from memory leaking issues when faced with circular references.
Is it still the case in the latest browsers? (e.g. Chrome, FF 3.5 etc)
From what I recall of a not too distant past, Javascript interpreters suffered from memory leaking issues when faced with circular references.
Is it still the case in the latest browsers? (e.g. Chrome, FF 3.5 etc)
To add to bobince answer, I did some tests with IE8.
I tried almost all examples provided at http://www.javascriptkit.com/javatutors/closuresleak/index.shtml
No one of them is leaking memory anymore (at least not in a perceivable way), except the example that removes child nodes with events still attached to them.
This type of example I think it's better explained by Douglas Crockford in his queuetest2.
This one still leaks memory on IE8 and it's pretty easy to test by simply running the test script and looking at Windows Task Manager - Performance - PF Usage. You will see PF Usage increases by almost 1MB per loop (very fast).
But in IE8 the memory is released on page unload (like navigating to a new page or reloading the same page) and obviously also when totally closing the browser.
So in order for a final user to perceive this memory leaks on IE8 (as reduced systerm performances), he needs to stay on the same page for a long time, which in now days it can frequently happen with AJAX, but this page need also to do hundreds of childnodes removal of elements with event attached to them.
Douglas Crockford test is stressing the browser with 10000 nodes added and then removed, that's excellent for showing you the issue, but in real life I never had a page that removed more than 10 elements. INMHO usually it's faster to use
display: none
rather than removing an entire set of nodes, that's why I don't useremoveChild
that much.For whoever might be more interested in the IE8 memory leak explained above, I did another test and it seems mem leaks do not show up at all in IE8 when using
innerHTML
in place ofappendChild/removeChild
to add/remove child elements with attached events. So apparently Douglas Crockford purge function (suggested by him to prevent memory leaks in IE) is not necessary anymore in IE8 at least when usinginnerHTML
...(EDITED thanks to 4esn0k comment below) ...moreover Douglas Crockford purge function does NOT work at all on IE8, in his code
var a = d.attributes
returns NOonclick
attributes (or any otheronevent
attributes) that were added at runtime on IE8 (they do are returned on IE7).Douglas Crockford says:
I provide here the code for the test:
The vast majority of leaks we talk about with JavaScript are specifically in IE6-7 when you make a reference loop between JavaScript objects and host objects like DOM nodes.
In IE6 this is particularly pernicious in that you don't get the memory back when you leave the page; it's gone until you quit the browser. In IE7 clearing out the page does now return the memory, but you can still have difficulty when you have a long-running application. IE8 solves most of this problem properly by turning the DOM nodes into native JavaScript objects instead of host objects. (You could still trigger the leaks in IE8 by including other non-native objects like ActiveX objects in a reference loop.)
There will certainly still be small obscure memory leaks lurking around in random places for all the browsers, especially in older versions. But there's no one way to easily categorise and avoid them like with the IE refloop issue.
Regarding Internet Explorer 8 - they say they have fixed it in MS IE8: http://msdn.microsoft.com/en-us/library/dd361842(VS.85).aspx
A similar thread here on StackOverflow: Do you know what may cause memory leaks in JavaScript?