Chrome has a heap snapshot tool that tells you where memory is being spent on a particular page. We should get this.

There are probably half a dozen bugs on this, but the one that looks most promising at the moment is Bug 625305.

(In reply to comment #1) > There are probably half a dozen bugs on this, but the one that looks most > promising at the moment is Bug 625305. Nope, that one is different. Chrome's tool is a snapshot for a particular page and breaks down the memory usage per object. Bug 625305 will only tell which page is using memory and not really give you any help in fixing it.

I removed the MemShrink annotation because this more a user-facing dev tool than a "the browser needs to be slimmer" tool.

The blog post has a good summary of using Chrome's tool: http://gent.ilcore.com/2011/08/finding-memory-leaks.html

One possibly fun twist here would be to allow user-defined predicates, written in JS, to distinguish JS Objects, which are otherwise just going to be a giant blob.

Type inference has boat-loads of information about objects; I bet that could be utilized somehow.

Found during bug triage (nearly a year later). This is definitely something I would love to have. CC'ing Shu for his Type Inference interests.

Is this still on the devtools team's radar? Debugging the memory allocation patterns in Shumway would be greatly helped by having such a tool.

Adding this to the performance Kanban. Need to log user stories associated with a heap tool. The main user story is to find memory leaks without having to record. As a app/web developer I would like to find memory leaks without having to run a recording so that I don't have to fill up my hard drive with useless data and so that I can find long term memory leaks. Acceptance criteria: - Be able to take heap snapshots - be able to do diffs on the snapshots

I'm working on memory tracking and it would be extremely useful for me. I'm attaching a screenshot of how this looks in Chrome DevTools. Here's the description: What I see on top is that there's an object (@50971) which uses 153kb of memory. Objects in total use 507kb, but that's the single biggest one. When I unfold it I see that it has tons of strings - it's our localization entries object. Now I see how it's structured. At the bottom I see that it's retained because of a reference from a variable "entries" which is referenced from a variable context which is referenced by an Array and Window object itself. That's super helpful. I can also wait a few seconds and do another snapshot and compare which objects were removed, added or modified and how it affected memory consumption. That's also useful. One thing that I miss heavily is ability to filter objects by file they were defined in.

Converting this to a user story to capture all the dependent user stories for heap snapshot analysis.

We've had a memory panel in the devtools for a while now. Anything more specific should be filed as new bugs. Thanks!