Performance and stability are massively undermined by startup of many tabs

RESOLVED WORKSFORME

Status

()

Firefox
Session Restore
RESOLVED WORKSFORME
6 months ago
3 months ago

People

(Reporter: mirh, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 months ago
So.. I'll start saying that I have this several years old firefox profile (on beta currently 53.0) with like around a thousand tabs. 
Startup times and 1-tab-loaded memory usage has always been hideous, but nothing I couldn't cope with after the first 5 minutes. 

Since a couple of week though, cpu usage is always 100% (of a single core, I have e10s disabled) even after startup and counting. Sometimes after a hour or something it finally calms down, other times only after I have used RestartFox to start the whole program again. 

I found your "Reporting a Performance Problem" MDN page, so I started profiling [on nightly(portable) because instructions says so]. I know you had even landed some lots-of-tabs related improvement and I was quite confident situation could be already better. 
It wasn't. 

After having understood how to replace sessionstore.js.... I blow FF up since x64 e10s completely swamped my RAM. 
I disabled multiprocess then.. And at this point I unfortunately discovered that the gecko profiler extension actually doesn't start monitoring anything until tabs are loaded in the first place. 

SO, I decided to profile instead the *restoration of a previous session*.. At the middle of which I get a "Script: chrome://global/content/bindings/browser.xml:348" hanging warning. 
Not something totally undeserved in all fairness. 

If I make it continue though, it crashes firefox. 
I finally managed to get to a working session by stopping it (and killing buttons and basically everything the UI does, but hey it was worth it). 

After trying to save to file the perf.html log, firefox hanged.. But thankfully I was able to find the gz.part archive in %temp% folder. 
https://perfht.ml/2pEdeVk Here for your delight. 

https://perfht.ml/2pHuNn8 This is instead some seconds taken from FF53beta with just "new tab" tab opened. 
Is it normal that for the love of me about:performance tab gives no load anywhere whatsover (contrarily to what's actually happening in fact)?

Thanks you all for your help. 
I'm sorry if the wordy description is messing up with somebody's time schedule or feelings, but I think I stumbled over so many problems that I wouldn't even know where to start.

Updated

6 months ago
Keywords: perf
(Reporter)

Comment 1

6 months ago
Created attachment 8860214 [details]
dd471a41-5ca8-42ac-a207-ea1a3eecaf21.zip

Crash log that for some reason I'm not able to send to crash-stats.
Produced on 20/04 x64 Nightly after accepting to continue "Script: chrome://global/content/bindings/browser.xml:348". I also had profiling enabled, if it can matter.
Blocks: 1330635
mirh, I'm sorry for the bad experience you've had here using Fx 53. We've been working very hard on this very subject the past few months and especially bug 1096013 - which is shipping with Fx 55 - will improve things drastically for your case.

Another bug we're expecting to show dramatic performance improvements is bug 1345090, which will also ship with Fx 55.

We'll keep monitoring this bug and I'm looking forward to your feedback when you try using Fx 55 with your profile!

Updated

6 months ago
See Also: → bug 1356605
(Reporter)

Comment 3

6 months ago
https://perfht.ml/2p358rf
My god, what of a difference bug 1345090 made. 
Unbelievable that I spent all that time testing, just hours short of the fix. 

Now anyway, I dunno whether you retain the perf-log above satisfactory (thus technically closing this bug), but while trying to save a memory report, I got firefox to hang (0% cpu and disk load). 
And lldb method mentioned on MDN returned an "error: use of undeclared identifier 'profiler_save_profile_to_file'". 

Moreover, I think the bugs that I was hitting which were making me crash are still there after all, and I'm just avoiding the trigger atm (special gift: https://pastebin.com/Mk89LaUh)

So.. tell me?
Thank you. 

p.s. for some reason, today FF53 seems pretty happy after [the long] startup too ^^
(In reply to mirh from comment #3)
> Moreover, I think the bugs that I was hitting which were making me crash are
> still there after all, and I'm just avoiding the trigger atm (special gift:
> https://pastebin.com/Mk89LaUh)

This crash is bug 1180561.
(Reporter)

Comment 5

6 months ago
Cool. Thanks for the hint. 

Now... Given NtWaitForMultipleObjects calls are possibly already covered by bug 1105634, I guess I should just leave open this bug for PresShell::Paint ? (that some strangers seemingly already made perf UI to point here)

Also, is there any friendly remainder/tracker for the lldb-windows enmity?
(Reporter)

Comment 6

6 months ago
Created attachment 8863523 [details]
crashes.zip

I'm not sure if this has anything to do with the bug or not, though today I was restarting 54.0b3 (since it was getting "slower") and it crashed while trying to close. 
I think I got OOM with minidump complaining about xul!workerlz4_decompress
(Reporter)

Comment 7

6 months ago
(In reply to mirh from comment #0)
> I disabled multiprocess then.. And at this point I unfortunately discovered
> that the gecko profiler extension actually doesn't start monitoring anything
> until tabs are loaded in the first place. 

Correction: this was actually me not expecting the browser to only being able to honor settings specified in other env vars when launched with MOZ_PROFILER_STARTUP

> After having understood how to replace sessionstore.js.... I blow FF up
> since x64 e10s completely swamped my RAM. 

This instead looks quite much like bug 1363240
Depends on: 1363240
(Reporter)

Comment 8

4 months ago
(In reply to mirh from comment #5)
> Now... Given NtWaitForMultipleObjects calls are possibly already covered by
> bug 1105634, I guess I should just leave open this bug for PresShell::Paint
> ? (that some strangers seemingly already made perf UI to point here)

That ntdll function still monopolize Running Time, though the whole thing is only a problem in relative terms now if any, rather than *absolute*. 

Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 months ago
Depends on: 1125557
Resolution: --- → WORKSFORME
(Reporter)

Comment 9

4 months ago
Forgot this.
Depends on: 1105634
You need to log in before you can comment on or make changes to this bug.