Open Bug 1809581 Opened 2 years ago Updated 1 year ago

Recently, the profiler starts taking incrementally longer time to process profiles after i profile a lot of profiles

Categories

(Core :: Gecko Profiler, defect, P3)

Product:
Core
Component:
Gecko Profiler
Type:
defect

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

Details

This started happening recently - maybe a week back

STR is to use the profiler to profile 10+ different profiles. As you keep on profiling a new profile, the profiler incrementally starts taking more time to process it.
And finally, if you then try to restart the browser, the browser doesnt shut down properly - I get a "Firefox is still running" message.

(the title of this bug can use better words, but I just dont know them)

I tried to reproduce, but after capturing 20 or so profiles in a row I didn't notice any slow down. I was probably missing some steps (eg. do you need to load pages? open and close windows while profiling?).

If you can, it would be really useful if you could profile the profiler using Linux Perf if you are seeing this on Linux, or Instruments if you are seeing this on Mac.

(In reply to Florian Quèze [:florian] from comment #2)

I tried to reproduce, but after capturing 20 or so profiles in a row I didn't notice any slow down. I was probably missing some steps (eg. do you need to load pages? open and close windows while profiling?).

I am profiling actual JS demos on fxhash.xyz/ . I open a demo in a new tab, run it, profile it, then close the profiler and the demo tab.

If you can, it would be really useful if you could profile the profiler using Linux Perf if you are seeing this on Linux, or Instruments if you are seeing this on Mac.
Im on Windows, and dont know enough to capture a profile..

Because this affects the browser shutdown, could this be related to serviceworker or something?

I would like to understand what you mean with the profiler incrementally starts taking more time to process it.. Is that happening before opening a new tab? Is that happening once the tab is opened and the animation inside the page is running? Is that happening after that?

Thanks for any more precision :-)

(In reply to Julien Wajsberg [:julienw] from comment #4)

I would like to understand what you mean with the profiler incrementally starts taking more time to process it.. Is that happening before opening a new tab? Is that happening once the tab is opened and the animation inside the page is running? Is that happening after that?

Thanks for any more precision :-)

  1. Open a new tab with a page (with a JS/canvas demo) you want to profile
  2. Run the demo
  3. Start the Profiler (i.e. press ctrl+shift+1 on my keyboard) Note: I usually have GFX preset + DOM Workers thread as my settings for the profiler
  4. Let the demo run for a few seconds - the Profile is being captured during this period
  5. Stop the Profiler to "process" the captured profile (i.e. press Ctrl+Shift+2 on my keyboard)
    6.1. The Profiler will open a new tab
    6.2 There will be animated horizontal colored lines while the profiler processes profiles
    6.3 The profiler UI will appear (the thread selector pane, the stack pane, the graphs etc.)
    6.4 The Profiler UI is populated with the graphs/data/captured profile
    Note: usually 6.3 and 6.4 are fast enough that they will appear as a single step
  6. Do analysis on the profile etc, and close the profiler tab

The slowness is from steps 6.1 to 6.4. Incremental means, that as you repeat steps 1-7, steps 6.1-6.4 take more time in each iteration.

Then, after I repeat steps 1-7 10+ times, the slowness occurrs. To fix that, I close the browser and start a new session. Here, when I try to start a new session by clicking on the Nighly desktop icon, I get the "Nightly is still running. Do you want to force quit this session and start a new session" message.

Hope this helps!

I'm still curious: is 6.1 also slow? I mean, is the amount of time between you pressing ctrl+shift+2, and firefox opening a tab, longer? Do all these steps 6.2 6.3 6.4 take a longer amount of time?
And finally, does anything in the profile catch your attention? For example does it contain more data than what you'd expect?

TBH this bug is very strange to me :-) If the bug is recent, would it be possible for you to run mozgression? There hasn't been many changes in the profiler codebase in Firefox in the past few weeks so I don't see anything suspicious...

(In reply to Julien Wajsberg [:julienw] from comment #6)

I'm still curious: is 6.1 also slow? I mean, is the amount of time between you pressing ctrl+shift+2, and firefox opening a tab, longer? Do all these steps 6.2 6.3 6.4 take a longer amount of time?

Yes, there is an increased delay between the time I press Ctrl+Shift+2 and the profiler opening a new tab.

And finally, does anything in the profile catch your attention? For example does it contain more data than what you'd expect?

Nothing that my untrained can eyes can see.

Here is a profile with all threads: https://share.firefox.dev/3w1guNW

Hope this is useful.

Flags: needinfo?(felash)

From your symptoms it looks like we're not discarding the data as we should, but your profile looks right...

Nazim, what do you think?

Flags: needinfo?(felash) → needinfo?(canaltinova)

Interesting. I tried to reproduce it myself too but couldn't.

I'm not sure what's happening here, but I will keep my ni request to investigate this further.
It looks like this profile is captured on Windows, it would be good to try to reproduce there as well.

Bug 1811473 has been filed for a symptom of what i think is the same underlying issue. That bug has a Networking focus.

See Also: → 1811473

I wonder if bug 1699681 could be the or one of the cause for this bug, as something that accumulates over several uses.

Another profile: https://share.firefox.dev/3D2a3xK

I created a patch that fixes Bug 1699681. Let's see if it will be helpful for this issue.

Flags: needinfo?(canaltinova)

What is meant by "Enabling the profiler with the JS feature " mentioned in bug 1699681 ? The config I choose on profiler is "Graphics preset + DOM Workers"

See Also: → 1699681

(In reply to Mayank Bansal from comment #14)

What is meant by "Enabling the profiler with the JS feature " mentioned in bug 1699681 ? The config I choose on profiler is "Graphics preset + DOM Workers"

Unless you unchecked the "JavaScript" checkbox in about:profiling, the JS feature is enabled. On a profile you already captured, the "Profile Info" panel has a list of the features that were enabled.

Severity: -- → S3
Priority: -- → P3

This has started occurring again since the last few weeks.

You need to log in before you can comment on or make changes to this bug.