Re: IE memory leak when removing elements from page? Inline

Peter Michaux wrote:

Hi,

Douglas Crockford mentioned in a video on Yahoo! that before removing
an element it is a good idea to purge it's event handlers. I think he
was only refering to the event handlers defined inline in the HTML
element attributes. This purging is because the event handlers create
the circular memory leak in IE.

I am trying to create and observe this memory leak with with IE6 and
the example below. I can't see any memory leaking.

I changed my test to the following to try to force the circular leak.
More memory definitely is used but during the test IE does seem to
garbage collect at times.

function doLoad() {
for (var i=1000000;i-- {
var p = document.createElement("p");
p.appendChild(document.createTextNode("clickme"));
p["onclick"]=(function(p){
return function(){alert("hi");};
})(p);
document.body.appendChild(p);
document.body.removeChild(p);
}
}

Peter

Peter Michaux wrote:

Peter Michaux wrote:
Hi,

Douglas Crockford mentioned in a video on Yahoo! that before removing
an element it is a good idea to purge it's event handlers. I think he
was only refering to the event handlers defined inline in the HTML
element attributes. This purging is because the event handlers create
the circular memory leak in IE.

I am trying to create and observe this memory leak with with IE6 and
the example below. I can't see any memory leaking.

I changed my test to the following to try to force the circular leak.
More memory definitely is used but during the test IE does seem to
garbage collect at times.

function doLoad() {
for (var i=1000000;i-- {
var p = document.createElement("p");
p.appendChild(document.createTextNode("clickme"));
p["onclick"]=(function(p){
return function(){alert("hi");};
})(p);
document.body.appendChild(p);
document.body.removeChild(p);
}
}

It looks like I was not interpreting the task manager output correctly.
The virtual memory usage was going crazy with this example. Looks like
Crockford was right as I expected.

Peter

Peter Michaux a écrit :

I am trying to create and observe this memory leak with with IE6 and
the example below. I can't see any memory leaking.

Because 'p' is a variable owning to the function, there will be any
memory leak. It could be to happen only if 'p' is a global variable.
When the function has finish its job used memory is automatically killed
(no more use of p in rest of code)

(if I've understood what I've heard - I haven't IE Win on my Mac)

Perhaps could you test with p as global ?

I changed my test to the following to try to force the circular leak.
More memory definitely is used but during the test IE does seem to
garbage collect at times.

function doLoad() {
for (var i=1000000;i-- {
var p = document.createElement("p");

p = document.createElement("p");

p.appendChild(document.createTextNode("clickme"));
p["onclick"]=(function(p){
return function(){alert("hi");};
})(p);
document.body.appendChild(p);
document.body.removeChild(p);
}
}

Peter Michaux wrote:

Peter Michaux wrote:
[...]
I changed my test to the following to try to force the circular leak.
More memory definitely is used but during the test IE does seem to
garbage collect at times.

function doLoad() {
for (var i=1000000;i-- {
var p = document.createElement("p");
p.appendChild(document.createTextNode("clickme"));
p["onclick"]=(function(p){
return function(){alert("hi");};
})(p);
document.body.appendChild(p);
document.body.removeChild(p);
}
}


It looks like I was not interpreting the task manager output correctly.
The virtual memory usage was going crazy with this example. Looks like
Crockford was right as I expected.

Yes, I think it's the inclusion of the element reference in the closure
that causes the leak.

If you want an even better demonstration (inspired by a Richard
Cornford post) head over to <URL:http://www.lipsum.com/> and generate
say 50 paragraphs of Ipsum lorem (should be about 30k of text). Paste
that into a div called 'xx' and modify your script to be:

function doLoad() {
for (var i=10000;i-- {
var p = document.createElement("p");
var x = document.getElementById('xx').innerHTML;
p.appendChild(document.createTextNode("clickme"));
p["onclick"]=
(function(p, x){return function(){alert("hi");};})(p, x);
document.body.appendChild(p);
document.body.removeChild(p);
}
}

For me it caused IE to swallow about 500MB of RAM each time the page
was loaded (after 2 you lose 1GB of RAM). It stays lost until IE is
closed. Note that I reduced the number of loops to 10,000.

--
Rob

Hi Rob,

RobG wrote:

<snip>

If you want an even better demonstration (inspired by a Richard
Cornford post) head over to <URL:http://www.lipsum.com/> and generate
say 50 paragraphs of Ipsum lorem (should be about 30k of text). Paste
that into a div called 'xx' and modify your script to be:

function doLoad() {
for (var i=10000;i-- {
var p = document.createElement("p");
var x = document.getElementById('xx').innerHTML;
p.appendChild(document.createTextNode("clickme"));
p["onclick"]=
(function(p, x){return function(){alert("hi");};})(p, x);
document.body.appendChild(p);
document.body.removeChild(p);
}
}

For me it caused IE to swallow about 500MB of RAM each time the page
was loaded (after 2 you lose 1GB of RAM). It stays lost until IE is
closed. Note that I reduced the number of loops to 10,000.

Thanks for the example and info. This closure and IE leak stuff is
starting to make more sense now.

I like the way that the Yahoo! UI event utility wraps this problem up
in the library. Just call YAHOO.util.Event.purgeElement() and the
element and all it's descendents are cleaned of their handlers.

Peter

Peter Michaux wrote:

Thanks for the example and info. This closure and IE leak stuff is
starting to make more sense now.

It may also help reading the explanation (and a formal excuse) of the
JScript engine creator:
<http://blogs.msdn.com/ericlippert/archive/2003/09/17/53028.aspx>

In the article Eric Lippert also says (about cancelling garbage
collection in such cases): "the application compatibility lab
discovered that there were actually web pages that broke when those
semantics were implemented. (No, I don't know the details.)"

I can provide these details. It was caused by unexperienced programmers
addressing DOM elements right after location.href=something or
document.write(something) on a loaded page.

Theoretically anything like that eliminates current page and script.
Practically script engine retains compiled code in the memory (with all
DOM references it had before) for some time. This creates the problem
of "orphan scripts" - thus of scripts still being excuted but having
lost the page which created them. If some of orphan scripts tried to
address a "virtual" (because already gone) DOM element using an old
reference, IE crashed rather miserably. By googling c.l.j. 3-4 years
ago you'll find a number of post on the subject. I even remember one
guy wanted to program a "orphan script emulator" to predict IE's
behavior.
The linked article is dated September 17, 2003. I presume the orphan
script "fix" was made somewhere earlier at that year; respectively 2003
is the year when the circular reference of this kind was born on IE.