720262 - Allow focusing a particular function in the profile

Status: RESOLVED WORKSFORME

(Core :: Gecko Profiler, defect)

Description

[Boris Zbarsky [:bzbarsky]]

When a function is focused, all samples outside that function should be ignored.

Comment 1

[Benoit Girard (:BenWa)]

Pushed:
https://github.com/bgirard/cleopatra/commit/292fce6657db38b056f2cdb2dd1f4787536fa905

To use this feature type the function name such as "glFinish" in the right hand side box. This will behave like 'instant search'. All backtrace not including glFinish will be replaced with 'Filtered out' until the text box is cleared.

Comment 2

[Boris Zbarsky [:bzbarsky]]

How do I try this out in practice?  Having things "replaced" as opposed to "hidden" doesn't sound like what this bug was asking for, but maybe I'm misunderstanding?

Comment 3

[Benoit Girard (:BenWa)]

Install the profiler extension on a recent nightly or use a pre-generated profile:

http://varium.fantasytalesonline.com/cleopatra/?report=AMIfv94hW4MYtwmJ1kePAq3QwG7pFIjSbRmBtybzJQJDXOHUZSk_qTT3LIQE2vf5OVixHpq74F_dYHtqdesr9Cg1AxEmxrHPrf34uqyeo2gumm7AwCvfaY1rJjst_WYTkM0C9FZbyHXjojJn8btOfUeoRBRu_hIA5A

In the right bar's filter text field type words like 'glreadpixels', 'malloc', 'LayerManager'.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Thanks.  That doesn't do quite what this bug was asking for.  Try loading that page and putting "ripl_BltShape" in the right-hand bar.  The expected behavior if this bug were fixed is that you have a tree showing "ripl_BltShape" as the root, with 10 samples under it to dig into.  But instead you see two subtrees (not counting the "unknown" subtree), with ripl_BltShape at different depths in them.

The primary use case for this bug's requested feature is dealing with situations in which a given function (e.g. "PresShell::DoReflow") is reached in a bazillion different ways in the profile (e.g. from several dozen different entry-points callable from JS) and you just want to investigate what's going on under that function no matter how it was reached....  The filtering approach currently implemented really doesn't let you do that.

Comment 5

[Benoit Girard (:BenWa)]

Thanks this is valuable feedback.

I though of doing it similar but you might be interested to know how that function can be reach and where does it go to so the function ends up anchored in the middle like how I have it implemented.

Not sure if this ASCII will turn out:
O\            /O
O--Focus Func--O
O/            \O

Comment 6

[Boris Zbarsky [:bzbarsky]]

I agree that having a way to find how the function can be reached would be valuable, but I think the right way to do that is to have a "blame all descendants to this function" option combined with a normal bottom-up (instead of top-down) profile

The problem with the ASCII-art proposal from comment 5 is that in my typical profiles the part on the left will have dozens of branches that are dozens to hundreds of stack frames deep each.  Maybe that will look ok in practice, but I'm not entirely convinced.

Comment 7

[Benoit Girard (:BenWa)]

This has been checked into the better-ui branch. You can now right click on a symbol and select 'Focus'. This focuses on the calles and by selecting 'invert callstack' you get the callers.

Comment 8

[Markus Stange [:mstange]]

(In reply to Benoit Girard (:BenWa) from comment #7)
> and by selecting 'invert callstack' you get the callers.

I don't like this. In Instruments I often act like this: First I drill down in top-down mode until I see a function that takes a lot of time. Then I focus on that function and change the view to bottom-up so that I can see what instructions take up the actual processor cycles inside of that function.
When 'invert callstack' changes to show only callers, I don't see what I want at this point.
If we want to add a way to show only the callers of the focused function, I think we should add another context menu entry.

Comment 9

[Benoit Girard (:BenWa)]

That's a good point. I think we will want to add that because profiler has really two key questions to answer. How can I make this function faster, and how do I call this function less (to have it run less). Focusing on the callers helps with the second question. Re-opening this bug until we add that.

Comment 10

[Markus Stange [:mstange]]

(In reply to Benoit Girard (:BenWa) from comment #9)
> how do I call this function less (to have it run less).

Hmm, I've never thought about it this way. Good point.

Maybe we could base the caller/callee choice on the mode we're in when clicking the menu item, and then keep it regardless of the mode that the filtered samples are viewed in.

Comment 11

[Benoit Girard (:BenWa)]

I think having two context menu items is really what is the most user intuitive. For example you may want to focus on the callers/call without wanting to switch and confusing your view.

We could get fancy have the breadcrumbs be something like 'Focus on 'XRE_main'<BR>(X) Caller ( ) Callee'.

Comment 12

[Markus Stange [:mstange]]

This was implemented in https://github.com/devtools-html/perf.html/pull/566 .