933048 - (short-term-leaks) Finding short term memory leaks

Status: NEW

(DevTools :: Memory, defect, P3)

Description

[Axel Kratel]

As an app/web developer, I would like to eliminate any short term memory leaks in my application so that I can minimize the memory consumption of my application.

Acceptance Criteria:
- Be able to take time snapshots on a recording to run a diff between object counts on the snapshots.
- Be able to force GC collection while recording. 

Note: we distinguish between short term and long term memory profiling since the latter would have different requirements from a recording perspective. Long term memory leaks would need to be measured without recording, or the recording would need a much lower footprint. Short term is <5 min time frame. Long term is anything above 5 min. (TBD, needs more discussion.)

Comment 1

[Axel Kratel]

See 625846 for finding long term memory leaks, i.e. by taking snapshots instead of recording.

Comment 2

[Julien Wajsberg [:julienw]]

I think this could still be a valuable addition to the current memory tool. We could reuse all the tools we already have, but provide an alternate UX.

Possible UX:
1. The user clicks on a "start session" button. The tool capture one snapshot.
2. The user clicks on a "stop session" button. The tool runs a GC then captures a snapshot.
3. The UI shows a diff between the 2 captures.

We could go even further:
1. The user clicks on a "start session" button. The tool capture one snapshot.
2. The user clicks on a "take capture and keep running" button. The tool runs a GC then captures a snapshot.
3. The user clicks on a "take capture and stop running" button. The tool runs a GC then captures a snapshot.
4. The UI shows the diffs between each captures.


Rather than being focused on individual captures, the UI would be focused on sessions, each one containing several captures and displaying diffs.

From my discussion with Alexandre I think this UI could be better when the developer tries to find a leak when running a specific scenario.

Comment 3

[Alexandre Poirot [:ochameau]]

What is missing from current memory panel experience is a GC button.

I'm not a big fan of sessions as you describe them here. It means that you would have to introduce new UI elements just for these sessions control, while keeping the existing UI to do records without GCs.
I'm not sure if that's clear for you, but you really want to keep both ways of recording. Sometimes you want GC and in some other cases you really don't want any.
You typically don't want any GC if you want to trace allocations and simply try to lower down the number of allocations.
Here you are not chasing leaks, but just trying to lower down peak memory usage.

You might be able to do something with a checkbox or multiple stop recording buttons, like perf-html with stop-and-discard vs open-profile-keep-recording.
I just feel it is more versatile to only add a GC button and let the developers find their very precise usage of GCs around snapshots.

Comment 4

[Julien Wajsberg [:julienw]]

I filed bug 1477997 for the GC button. I agree this is both an easy addition and a very valuable tool.
I still think a dedicated view to find leaks would be useful, but let's play a bit with our tool before starting something crazy :-)