Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] Reporter
	Description • 10 years ago

I can think of two types of memory data that can be measured over a period of time and would make sense to integrate into the performance/timeline tool.

1. Allocations

I can factor out the allocations RDP stuff from bug 960671 pretty easily and once bug 1056373 and bug 1032869 land, we will be able to sample allocations with fairly low overhead.

We can graph allocations live in a really neat way as a flame graph, and we can also have a live-updating (invert-able) tree view (like the profiler has at the bottom).

If you are seeing GC pauses, this data is very actionable. Allocations cause GC pressure, which causes GC cycles. Minimize your allocations and you will minimize the number and length of GC pauses.

2. Memory Consumption

We can get approximate consumption numbers for a few different buckets of things on the heap via MemoryActor's measure method right now.

We can get exact numbers of live, reachable things on the heap categorized by [[Class]], constructor, or allocation site via Debugger.Memory.prototype.takeCensus (and I have RDP implementation for getting this data in bug 960671 that I can factor out). However, this isn't currently as fast as we would like it to be. What this means is we would either have to require the user to opt in to these measurements in some way (say by ticking a checkbox), or we need to wait until we can speed up the implementation. I will let Jim provide more information about the latter.

Graphs of this data can clue you in to when you might have a leak and hint at when you may want to use a heavier memory analysis tool, like a heap snapshot tool, but I don't think it is as directly actionable as the allocations data above. Obviously, the more detailed of a breakdown you have the more actionable it gets. An app has to use memory, that is expected, but what is valuable is comparing reality to your expectations. For example, "I didn't realize that 50% of my app's memory usage is spent on splay tree nodes!" or "wow! that third party social networking widget that's hidden and hasn't been viewed yet is using that much memory?!"

	Jim Blandy :jimb
	Comment 1 • 10 years ago

Re: speeding up Debugger.Memory.prototype.takeCensus:

The implementation of takeCensus uses JS::ubi::Node to traverse the heap graph and count what it sees. At the moment, JS::ubi::Node uses SpiderMonkey's public JS_TraceChildren API to produce the edge list for every kind of object. However, that API goes through several levels of calls and switches to produce the edge list, and they show up in Valgrind cachegrind profiles of traversals. I think a custom EdgeRange implementation for JSObject could improve performance quite a bit.

	Paul Rouget [:paul]
	Comment 2 • 10 years ago

re: Memory Consumption vs Allocations, do we know what Chrome and IE do?

	Paul Rouget [:paul]
	Comment 3 • 10 years ago

How do we want to start? Adding this graph within the timeline or the profiler? Victor, any recommendation?

And should we split this bug in two bugs (backend & frontend)?

	Victor Porof [:vporof][:vp]
	Comment 4 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #3)
> How do we want to start? Adding this graph within the timeline or the
> profiler? Victor, any recommendation?
> 

We talked about this in person. Timeline.

> And should we split this bug in two bugs (backend & frontend)?

I don't think so.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] Reporter
	Comment 5 • 10 years ago

Note that :njn had some great feedback on the allocations tree view in bug 960671 comment 33, and whoever ends up integrating that into the performance panel should take it into serious consideration.

	Alex Art
	Comment 6 • 10 years ago

Have you ever seen Java's (Netbeans) profiling tool?
It's a pleasure to work with it when you hunting a memory leak or something.
You are turning on the memory profiler for a while, it collects information from memory about objects their quantity, lifetime, size (recursively summarizing if developer selects only certain package/class name could be great here and there) and generations. And the most greatest thing, it shows them in code-view and has a plenty of greatest filters to display objects by name, package name etc.

	Victor Porof [:vporof][:vp]
	Comment 7 • 10 years ago

This was added in bug 1077461 and bug 1077469.

	Victor Porof [:vporof][:vp]
	Comment 8 • 10 years ago

For any improvements or additions to the existing implementations, please file separate bugs.

	David Lawrence [:dkl]
	Comment 9 • 9 years ago

Sorry for the spam. Moving bugs to Firefox :: Developer Tools: Performance Tools (Profiler/Timeline).

dkl