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.

Answer 2

It's fixed! - UPGRADE BACKBONE. (continue reading)

We upgraded from Backbone 0.9.2 to Backbone 0.9.10 and implemented the listenTo and stopListening on every view/model/collection. The results are OMGFANTASTIC.

After 7 minutes of running the same stress-test, these are the results:

Results: 7.0 minutes, 6,926 DOM Nodes (Without the timeline recording) and the Event Listener Count looks like BLUE BLADES OF GRASS. I'm shocked. The memory usage is also amazingly low in comparison to previous tests.

After 18 Minutes: The event listener count is the same, never surpassing 154 and the DOM Node Count stays below 25,000 the entire time! There are obviously some things slipping by (some non-backbone components that are still in use, most-likely) but the improvement is astounding.

Conclusion: Prior to this version of Backbone, we were not doing a very good job cleaning up listeners within Backbone itself. The listeners to the DOM were handled fine, but not between models/views/collections. Many of the callbacks involved were tied to Backbone Views which I guess prevented the garbage collector from freeing up the DOM Nodes. Lots of straggling event listeners/callbacks within Backbone (not just binding to the DOM) create a lot of straggling DOM Nodes that can't be garbage collected.

If this isn't a good enough reason to upgrade Backbone, I don't know what is ;o

Answer 3

The rising DOM nodes count is the main sign of a memory leak (usually in the code of our page). So you need to fight against it. The standard technique is described in the answer to this question.

The snapshot content has too many details. And this 3 snapshot schema helps you to filter out not interesting part of the snapshot and shows only the candidates for a leak.

Please be sure that you are running the latest version of chrome, as example Chrome Canary. It should be a fresh instance with single tab without extensions. It would be nice to have no error messages in console, no breakpoints and do not stop on an exception because all these things may affect the page and as a result the snapshot content.

This post might be interesting for you too.

Answer 4

i found another way to avoid jank

render: function() {
  this.$el.empty();
  var container = document.createDocumentFragment();
  // render each subview, appending to our root element
  _.each(this._views, function(subview) {
     container.appendChild(subview.render().el)
  });
  this.$el.append(container);
}

refer it here http://ozkatz.github.io/avoiding-common-backbonejs-pitfalls.html