Best implementation of setTimeout / clearTimeout

[bizt]

Hi,

I have a process where every so often I refresh a table's data using a
setTimeout() .. and when its no longer needed, a clearTimeout().

The following is a simple example of how this is done:

var goMenuTimeout = null;
function LoadMenu() {
// cancel any repeat actions
clearTimeout(go MenuTimeout);

// do some loading stuff

[Thomas 'PointedEars' Lahn]

Re: Best implementation of setTimeout / clearTimeout

bizt wrote:

I have a process where every so often I refresh a table's data using a
setTimeout() .. and when its no longer needed, a clearTimeout().
>
The following is a simple example of how this is done:
>
var goMenuTimeout = null; function LoadMenu() { // cancel any repeat
actions clearTimeout(go MenuTimeout);
>
// do some loading stuff . . .
>
// set timeout to refresh in 60 seconds goMenuTimeout =
setTimeout("Loa dMenu()", 60000); }
>
This is just one example however my app has many setTimeouts to refresh
various elements. Now, the problem I may have is memory leaks and this is
one area I reacon it may be happening where objects created with
setTimeout are not being cancelled properly with clearTimeout() and over
time they are being retained in memory. Could this be the case even tho I
am using clearTimeout()?

Yes, objects created in code evaluated through window.setTimeo ut() are not
automatically garbage-collected when window.clearTim eout() is called.

I have also seen the following implementation:
>
clearTimeout(ti meoutID); delete timeoutID;
>
This is how I have seen this process done on the MDC and some other
sites, will this reduce memory usage?

If `timeoutID' was *not* declared a variable (and so the created property
would lack the DontDelete attribute), then the additional `delete' operation
would probably save about 12 bytes of memory (32 bits [4 bytes] for the
variable pointer and 64 bits [8 bytes] for the IEEE-754 double-precision
floating-point value that it points to).

As far as I was aware clearTimeout() would destroy the repeating object
in the variable,

The return value of window.setTimeo ut() and the argument that
window.clearTim eout() expects is a number value that is the index of the
timeout/interval in the internal timeout/interval registry of the host
environment, not a direct reference to an object.

does it still get retained in memory?

If the aforementioned index specifies an object to implement the code to be
executed on timeout/interval click, then that object will allocate memory
until it is garbage-collected.

I have noticed that when I do alert(goMenuTim eout) each time it gives me
a different timeoutID value each time so I suspicious that perhaps these
timeout objects are getting retained and over time memory is being
allocated to redundant objects.

Although there is probably no timeout object as such, your suspicion is
warranted. The redundant objects would more likely to be the objects that
you create in the "do some loading stuff" part of the code instead.

Btw when I talk about memory leaks I meaning when I first load up
Firefox, in Windows Task Manager it is using 32KB of memory, but as

Probably you mean 32 _MiB_ of memory. I have yet to see a Firefox version
with an initial memory footprint lower than 20 MiB.

time goes on (ie. 20/30 minutes) it can be as high as 80/100KB with only
one tab open - in that time the app may have done one or two hundred
timeout processes. I have noticed once when the browser has been open for
a few hours that usage has risen to 400+KB which seems quite extreme

There are other factors to consider, though: browser version (2.0.x leaked
much more memory than 3.0.x does), add-ons and plugins that leak memory, and
so on. Most important is that new browser windows do not create new browser
processes, and therefore contribute to the total memory footprint of the
single browser process (you were emphasizing that you have only one tab open
in the window in question).


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee