1358283 - Performance and stability are massively undermined by startup of many tabs

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[mirh]

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.

Comment 1

[mirh]

Attachment: 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.

Comment 2

[Mike de Boer [:mikedeboer]]

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!

Comment 3

[mirh]

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 ^^

Comment 4

[Markus Stange [:mstange]]

(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.

Comment 5

[mirh]

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?

Comment 6

[mirh]

Attachment: 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

Comment 7

[mirh]

(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

Comment 8

[mirh]

(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.

Comment 9

[mirh]

Forgot this.