1233551 - Let the allocations view ride the trains

Status: RESOLVED FIXED

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Ship it!

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: Do not mark the allocations profiling as experimental

This commit unmarks the allocation stack sampling as experimental, allowing it
to be visible by default, and no longer restricted to Nightly only.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c7216387cad6

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/b112cff0cede

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b112cff0cede

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Will, would love to have some docs on the allocations profiling (which was just enabled in this bug, not implemented). Please let me know what I can do to help!

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: allocations recording option

After this patch, the warning sign is gone and this option will be available outside of just nightly (I have an older build here so I still have the warning sign).

This is how you toggle the allocations recording on and off.

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: allocations tab in recorded profiles

When you record a profile with that option set, you get a new tab. This is what it looks like. It shows you the number and size of allocations. The percents are what should be focused on: this is a sampling mechanism, so we only see about 1/20 allocations IIRC. We could definitely improve the UI to focus on that more, but that's a bit of an aside.

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: minor gcs shouldn't generally be worried about, usually very fast

Going to attach a few screenshots to illustrate how to know *when* to use the allocations tab, and how it ties back into general profiling.

See here that minor GCs generally should be ignored as they are *very* fast (slower than usual on this benchmark, usually less than 1 ms, fixing this particular cliff in bug 1233857).

Comment 9

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: non-incremental GCs are a HUGE RED FLAG!

non-incremental, major GCs (any GC not explicitly labeled minor is major) are the worst: it means that you were allocating so much that we couldn't keep doing incremental gc (where we do a little bit of GC work, let the page run, do a little more GC work, let the page run, etc) and had to stop the page completely while we did a full GC.

Note the "show allocation triggers" button in the side bar. Next screenshot will be what happens when you click that.

Comment 10

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: clicking "show allocation triggers" jumps you to the allocations tab

Clicking that button jumps you to the allocations tab and selects the region of time from the end of the last GC cycle to the start of the one you clicked on. This shows you all the allocations that collectively put enough pressure on the garbage collector that it was forced to stop the page and do its clean up.

Questions to ask yourself: which of these allocations could be elided? Can some of these allocations be done lazily instead of up front? Am I allocating in a loop? If so, can I reuse one allocation for every iteration of the loop, or do I really need to allocate on every iteration? Etc...

------

Ok, that's all I have right now, please let me know if there are things I can make more clear or if you have any other questions.

Thanks, Will!

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Might this be good for a release note for 46?

Comment 12

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11)
> Might this be good for a release note for 46?

Yes, I think a nice wording might be something like:

"""
Allocation and GC pause profiling in the DevTools' performance panel.
"""

How does that sound?

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds good to me!   

Release Note Request (optional, but appreciated)
[Why is this notable]: New function in profiler visible to users
[Suggested wording]: Allocation and GC pause profiling in the performance panel
[Links (documentation, blog post, etc)]:

Comment 14

[Will Bamberg [:wbamberg]]

OK, Nick, I'll have something soon.

Comment 15

[Will Bamberg [:wbamberg]]

I've written:
https://developer.mozilla.org/en-US/docs/Tools/Performance/Allocations

and made minor updates to:
https://developer.mozilla.org/en-US/docs/Tools/Performance
https://developer.mozilla.org/en-US/docs/Tools/Performance/UI_Tour
https://developer.mozilla.org/en-US/docs/Tools/Performance/Waterfall#Garbage_collection

You've already seen the main doc here and I've applied the comments, so I'm going to mark this dev-doc-complete, but please let me know if you see anything else.

Comment 16

[Will Bamberg [:wbamberg]]

:lizzard, you could point the release notes at https://developer.mozilla.org/en-US/docs/Tools/Performance/Allocations

Comment 17

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Looks great! Thanks!

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks Will!

Comment 19

[Mayur Patil]

[bugday-20160323]

Status: RESOLVED,FIXED -> UNVERIFIED

Comments:
STR: Not clear.
Developer specific testing

Component: 
Name			Firefox
Version			46.0b9
Build ID		20160322075646
Update Channel	beta
User Agent		Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
OS				Windows 7 SP1 x86_64

Expected Results: 
Developer specific testing

Actual Results: 
As expected