Deleting an anonymous function

[Gregor Kofler]

What is the best practice for removing anonymous functions?

Something like
(function() { doSomething(); arguments.calle e = null; })();

seems to work (at least it triggers no errors or exceptions on FF, but
is this really a working solution?

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[David Mark]

On Aug 1, 6:19*pm, Gregor Kofler <use...@gregork ofler.atwrote:

What is the best practice for removing anonymous functions?

Something like

(function() { doSomething(); arguments.calle e = null; })();

seems to work (at least it triggers no errors or exceptions on FF, but
is this really a working solution?

You don't need to set arguments.calle e to null. It is fine without
that line.

[RobG]

On Aug 2, 8:19*am, Gregor Kofler <use...@gregork ofler.atwrote:

What is the best practice for removing anonymous functions?

Leave them for the garbage collector. Do you attempt to explicitly
remove named functions?

It seems to me that:

var foo = function(){ /*foo body */ };
foo();
foo = null;

results in the function formerly referred to as foo becoming anonymous
and, if there are no other references to it, it becomes available for
garbage collection.

It is, more or less, equivalent to:

(function(){ /*foo body */ })();
provided foo isn't called from elsewhere before being set to null.

Something like

(function() { doSomething(); arguments.calle e = null; })();

seems to work (at least it triggers no errors or exceptions on FF, but
is this really a working solution?

It depends on what you interpret from the phrase "seems to work". The
arguments object belongs on to the execution context, it is given a
'callee' property that refers to the anonymous Function so that it can
be recursive. It has the property DontEnum, but is not specified as
being ReadOnly so you can set it to anything you like without causing
an error (in a browser conforming to ECMA-262, section 10.1.8).

Setting arguments.calle e as a reference to some arbitrary object
doesn't seem to do anything useful and should have zero effect on when
the function is made available for garbage collection.
--
Rob

[Gregor Kofler]

David Mark meinte:

On Aug 1, 6:19 pm, Gregor Kofler <use...@gregork ofler.atwrote:

>What is the best practice for removing anonymous functions?

Something like

(function() { doSomething(); arguments.calle e = null; })();

seems to work (at least it triggers no errors or exceptions on FF, but
is this really a working solution?

You don't need to set arguments.calle e to null. It is fine without
that line.

To clarify that: An anonymous function gets removed by GC even if it's
content is "more complicated" including closures?

Something like:

(function() {
var counter = 0, id;
id = window.setInter val(function() {
document.write( counter++);
if(counter 100) {
window.clearInt erval(id);
}
}, 1000)
})();

Well, perhaps I'm just suffering some memory-leak-paranoia...

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

>Well, perhaps I'm just suffering some memory-leak-paranoia...

I think your concern is certainly based on reasonable grounds.

I've just tried this on FF w/ Firebug:

for(var k = 100; --k;) {
(function() {
var stack = [], id, counter = 0;
id = window.setInter val(function() {
var s = [];
for(var j = 1000; j--;) {
s.push("xyz", "abc", "def");
}

stack.push(s);
console.log(cou nter);

if(++counter 100) {
window.clearInt erval(id);
}
}, 100)
})();
}

The memory usage of FF goes up from approx. 76MB to around 290MB, then
(after clearing the console) to 77MB, a reload pushed it again to 290MB
before returning to (hooray!) 76MB.

It's of course a bit pedestrian, but the GC seems to collect all the
unused stuff properly.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Gregor Kofler]

Richard Cornford meinte:

[something I'll try to grasp later]

>>Well, perhaps I'm just suffering some
memory-leak-paranoia...

I think your concern is certainly based on reasonable
grounds.

Given the increase in AJAX projects where the intention is not to
navigate way form a 'page' for long periods of time and the increased
use of (less then optimally implemented) functional programming
structures (particularly in 'popular' libraries) it does seem reasonable
to gauge the extent to which this is an issue.

I idea is some "flash-once" highlighting of elements on the page; a
setTimeout/setInterval that does some color or opacity manipulation
packaged in an anonymous function - fire and forget. However, in this
very application one could accumulate quite a few of those highlighters.

Executing these scripts in one page and then navigating to an
"about:blan k" homepage and recording the defences in memory use between
the two pages loaded states, and repeating a few times, the results were:-

For test A the difference between "about:blan k" loaded and the post-test
code execution of the test page were; ~76 Megabytes more for the test
script.

Test B; ~145 Megabytes

Test C; ~128 Megabytes

Conclusion: In the environment tested (JScript) the normal process does
not raise an issue. If, however, the - arguments - object is explicitly
preserved then the memory consumption does increase significantly, and
given that explicitly clearing the - arguments.calle e - in test C did
decrease the extent of that memory increase it would be reasonable to
conclude that some of that memory increase (~17 Megabytes) is accounted
for by now non-garbage collectable outer function objects.

Thanks for testing - very interesting indeed.

If nobody else gets there first I will try out similar tests on other
browsers soonish.

Greatly appreciated.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Richard Cornford]

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:

>>Well, perhaps I'm just suffering some
memory-leak-paranoia...

I think your concern is certainly based on reasonable
grounds.

I've just tried this on FF w/ Firebug:

for(var k = 100; --k;) { (function() {
var stack = [], id, counter = 0;
id = window.setInter val(function() {
var s = [];
for(var j = 1000; j--;) {
s.push("xyz", "abc", "def");
}

stack.push(s);
console.log(cou nter);

if(++counter 100) {
window.clearInt erval(id);
}
}, 100)
})();
}
The memory usage of FF goes up from approx. 76MB to around
290MB, then (after clearing the console) to 77MB, a reload
pushed it again to 290MB before returning to (hooray!) 76MB.

It's of course a bit pedestrian, but the GC seems to collect
all the unused stuff properly.

This is a test for a memory leak, and not finding one is good. But I
don't think anyone was expecting to find a memory leak here anyway.
Circular chains of references between pure javascript objects have never
been a garbage collection issue once there are no external references to
any of the objects involved.

You have shown ~2 Megabytes per loop iteration of memory consumption,
and those of us who used 1980's computers, where having 2 Megabytes of
memory would have been unusual, may find that a little shocking. For an
in-page AJAX web application the important question may not only be the
overall garbage collection effectives but also the memory footprint of
the running application, so if that per iteration memory consumption
could be reduced by freeing more objects sooner that may be significant.
You have shown that the outer function gets garbage collected
eventually, but not that it can be garbage collected as soon as its
execution context is finished.

Richard.

[Richard Cornford]

Gregor Kofler wrote:

Richard Cornford meinte:

<snip>

>>>Well, perhaps I'm just suffering some
memory-leak-paranoia...

I think your concern is certainly based on reasonable
grounds.

<snip>

>... it does seem reasonable to gauge the extent to which this is an
issue.

<snip>

>Conclusion: In the environment tested (JScript) the normal
process does not raise an issue. ... .

Thanks for testing - very interesting indeed.

>If nobody else gets there first I will try out similar tests
on other browsers soonish.

<snip>

Looking at this on Firefox and Opera (various recent versions) produced
pretty much the same pattern as IE. So there is no need to worry about
closures needlessly preserving references to outer function objects
through - arguments/arguments.calle e - in those environments either.

Windows Safari was more of a problem as the test code used for Opera and
Firefox killed its ability to execute javascript (strangely, as it was
quite happy to carry on displaying HTML pages and navigate, etc. it just
would not execute any more javascript of any sort until shut down and
re-started). It seems that the Safari's issue related directly to the
number of closures being formed (the number of iterations in the loops).
Unfortunately reducing the length of the loops to the point where Safari
could survive the test code resulted in the changes in memory use
measured for the tests being too small to be conclusive.

Richard.