javascript - Backbone.js Memory Management, Rising DOM Node Count

Question

Situation: I'm working on a pretty decently complex single page Backbone app that could potentially be running for 8-12+ hours straight. Because of this, there's a need to ensure that the application won't leak and have a reputation for crashing after X hours or slow down dramatically.

The Application: The app is built on Backbone (mv*), Zepto (similar to jquery), Curl (amd loader) & Mustache (templating).

Problem: I've just conquered the event listeners. The garbage collector seems to be doing a fine job cleaning these guys up, but the DOM Node Count won't stop climbing.

Questions:

• Is there a proper way to dispose of DOM Nodes so that they will be properly garbage collected, or is this DOM Node Count a running total that will never decrease?
• Does anybody know of any of these frameworks to poorly handle DOM Nodes? Possibly Mustache?
• Is the DOM Node Count even a reliable figure?

I'm really just looking for a head start on my adventure to stop these DOM Nodes from rising. Any help or guidance would be greatly appreciated (and accordingly upvoted).

I assumed that once the event listeners were properly disposed of that the DOM Node Count would just manage itself, but this doesn't seem to be the case.

Tests

---

• First Test: 6.8 minutes, 110,000 DOM Nodes

---

Edit: Without the Timeline recording, I reran the same script to randomly mash links and took a screenshot at around the 7 minute mark. After GC came through I had these results.

• Second Test: 7.1 minutes, 141,000 DOM Nodes (Without the timeline recording)

---

Edit: After Fix:

After Upgrade Backbone and using listenTo and stopListening everywhere

• 7 minutes: 6,926 DOM Nodes (see marked answer below).
• 20 minutes: 6,000 DOM Nodes, 20 Event Listeners, Memory 20 MB.
• 25 minutes: 11,600 DOM Nodes, 44 Listeners, Memory 21.7 MB.
• 28 minutes: 9,000 DOM Nodes, 22 Event Listeners, Memory 21.7 MB.
• 30 minutes: 13,700 DOM Nodes, 123 Event Listeners, Memory 21.7.
• 31 minutes: 7,040 DOM Nodes, 30 Listeners, Memory 21.7.

Answer 1

I assumed that once the event listeners were properly disposed of that the DOM Node Count would just manage itself, but this doesn't seem to be the case.

If I got you right you are trying to dispose of the node by removing listeners from it, is that the case?

Note that adding event listener to a DOM node doesn't prevent the node from being garbage collected, the dependency is in opposite direction: while the node is alive the listener function will not be collected.

• Is there a proper way to dispose of DOM Nodes so that they will be properly garbage collected, or is this DOM Node Count a running total that will never decrease?

To make sure a DOM node can be garbage collected you should

1. Remove the node from the document tree.
2. Clear all references from javascript to the node AND to all nodes in the same subtree as reference from javascript to one of the nodes in the subtree will hold whole subtree.

So it is not enough to just remove listeners from a node to make it collectable. Moreover, it is not necessary to remove listeners from a node if you want the node to be collected.

The DOM node count should be decreasing when some nodes are collected by GC and destroyed. The number indicates current amount of DOM nodes that have been created but not destroyed so it shouldn't grow indefinitely unless there is a memory leak.

• Is the DOM Node Count even a reliable figure?

Yes. It should be a reliable figure as it is incremented whenever a new DOM node is created and decremented when it is destroyed. So the implementation is quite straightforward to trust it.