i know most of you will point me to the chrome profiler heap snapshot, but on empty page (no js no css just html>body) it shows 8mb heap size and 12 to 30 thousand objects depends on his mood, so it is totally useless tool for this task, and i think this heap profiler has its own humble opinion on data it shows rather then fact, though rest of chrome dev tools are awesome.

Basically my backbone 1page app keeps growing in memory even though i'm doing all possible garbage collection dance, JSON.stringify(Obj).length throws action not secure on most objects, how i can track down those zombies easier then trial and error.

i know most of you will point me to the chrome profiler heap snapshot, but on empty page (no js no css just html>body) it shows 8mb heap size and 12 to 30 thousand objects depends on his mood, so it is totally useless tool for this task, and i think this heap profiler has its own humble opinion on data it shows rather then fact, though rest of chrome dev tools are awesome.

Basically my backbone 1page app keeps growing in memory even though i'm doing all possible garbage collection dance, JSON.stringify(Obj).length throws action not secure on most objects, how i can track down those zombies easier then trial and error.

• javascript
• memory
• backbone.js

• Use the snapshot difference functionality in chrome: Snapshot an empty page, do some test, snapshot again, diff. – John Dvorak Commented Jan 23, 2013 at 12:03
• dont forget the dev tools interface itself is built in javascript, i'm pretty sure it has an impact. – mpm Commented Jan 23, 2013 at 12:23

1 Answer 1

You diss the Chrome Developer Tools, but as far as I know, they're the best you got. You just have to use them judiciously.

Say you want to test whether some action in your application leaks memory. It could be the rendering of a view, or fetching some new data. Let's call this the Action.

In order to to find out how much memory is reserved, and how much is retained, first you need to get a measurable baseline, and get rid of the noise. You need three steps to achieve those things.

1. Warm-up

   Start your application (navigate to your website). Perform Action. Take a heap snapshot. This snapshot is discarded, but it'll run the GC and get you a clean slate. The warm-up also ensures that you don't get any fuzz on your measurable data: script evaluation, initial loading resources async etc.

2. Baseline

   Perform Action three times. Take a heap snapshot. This is the baseline to which we'll pare our memory resevation and retention. We do the Action three times to get a sensible average in case there is some small variability in the execution path. Make sure to try to repeat the Action exactly the same way every time.

3. Measurement

   Perform Action three times. Take a heap snapshot.

Now you'll have three snapshots. The first will be discarded, but what's interesting for us are the Summary for Objects allocated between snapshots 2 and 3, as well as the delta Comparison from Snapshot 3 to Snapshot 2. You can find these views from the bottom/status bar of the Profiles view.

The data you see between the Baseline and Measurement shapshots is the true memory profile for Action. After that you just need to know how to interpret the data correctly. For that I remend Google's documentation on the profiler.

I don't think there exists a better tool or a way at this time. If there does, I would love to hear about it.