I have a GreaseMonkey script that works on a site that uses frames as an integral part of its interface. This script leaks memory like a sieve, and I believe it is due to my use of addEventListener within one of the frames. Quite simply, I attach a variety of event listeners, then the frame reloads and I attach the event listeners, and then the frame reloads, around and around for hundreds or possibly thousands of iterations as you interact with various elements in this frame or others. By the end of it, Firefox has gone from ~300M of memory to as much as 2G (or crashes before it gets there).
I read somewhere that doing a full page reload would allow FireFox's garbage collection routines to kick in and recover all the memory from orphaned event handlers, and sure enough when I hit F5 after my script has run for a while, within about 10 seconds the memory is back down to 300M. Unfortunately this breaks a different frame in the site (a very popular chat window), so while it does seem to confirm my suspicion that addEventListener is to blame, it's not really an option as a solution.
Is there something else I can do to free up the memory properly without forcing a full page refresh?
(Currently using GM 1.5 and FF 17, but the issue has existed since GM 0.8/FF 4 or thereabouts.)
Without seeing your complete script, or a Short, Self Contained, Compilable Example, we can't be sure of what is going on. It may be that addEventListener
is not the problem.
Here are some strategies for better code, with fewer memory leaks:
Inline/anonymous functions are often a culprit, especially with event handlers.
Poor / Leaky:
elem.onclick = function () {/*do something*/};
elem.addEventListener ("click", function() {/*do something*/}, false);
$("elem").click ( function () {/*do something*/} );
Not leaky and also easier to maintain:
elem.onclick = clickHandler;
elem.addEventListener ("click", clickHandler, false);
$("elem").click (clickHandler);
function clickHandler (evt) {
/*do something*/
}
Note that for userscripts you should avoid onclick
, etc. anyway.
Likewise do not use JS on HTML attributes. EG don't use <span onclick="callSomeFunction()">
, etc.
Minimize the code that runs in iframes to only that code you explicitly want.
- Use the
@include
, @exclude
, and @match
directives to block as many unwanted iframes as possible.
Wrap all code that doesn't need to run in iframes in a block like so:
if (window.top === window.self) {
// Not in a frame
}
Do not use innerHTML
.
For lots of elements, or elements that come and go with AJAX, do not use addEventListener()
or jQuery's .bind()
, .click()
, etc.
This replicates the listener across, potentially, thousands of nodes.
Use jQuery's .on()
. That way the listener is attached only once and triggers appropriately via bubbling. (Note that in some rare-ish cases .on()
can be blocked by the page's javascript.)
In your case, you probably want something like:
$(document).on ("click", "YOUR ELEM SELECTOR", clickHandler);
function clickHandler (evt) {
/*do something*/
}
To avoid surprise circular references or orphaned items, use jQuery to add or remove elements, rather than direct DOM methods like createElement()
, appendChild()
, etc.
jQuery is designed/tested to minimize such things.
Beware of overusing GM_setValue()
. It easily can use lots of global resources or cause a script instance to crash.
- For same-domain values, use
localStorage
.
- Do not use
GM_setValue()
to store anything but strings. For anything else, use a serializer such as GM_SuperValue
. Even innocent looking integers can cause the default GM_setValue()
to crash.
- Rather than store lots of small variables, it may be better to wrap them in an object and store that with one of the serializers.
Always check return values and assume that elements can be missing:
This is poor (and, alas, typical):
$("selector").text($("selector").text().match(/foo=([bar]+)/)[1]);
Better:
var salesItemDiv = $("selector");
var fooMatch = salesItemDiv.text ().match (/\bfoo\s*=\s*([bar]+)\b/i);
if (fooMatch && fooMatch.length > 1) {
salesItemDiv.text ( fooMatch[1] );
}
possibly followed by:
salesItemDiv = fooMatch = null;
see below.
Beware of recursive / inline setTimeout()
calls. Use setInterval()
for repeated timing. Just like with event handlers, do not use inline/anonymous functions.
Run your code through JSLint.
Avoid eval()
and auto/hidden eval()
invocations.
Set variables to null
when you are done with them. See this, for example.
Reference: "Do you know what may cause memory leaks in JavaScript?"
Additional reading on JS memory leaks
Mozilla Performance: Leak Tools