Performance degradation on 78 version of desktop browser: tab switching lags, keyboard input lags severly
Categories
(Firefox :: Untriaged, defect)
Tracking
()
| Performance Impact | ? |
People
(Reporter: victor.suzdalev, Unassigned)
Details
(Whiteboard: [MemShrink])
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
I'm using browser just as always (~10-15 tabs, switching here and there, listening to streaming music or youtube). After browser update switching between the tabs is painfully slow (I'm seeing gray FF loaders on every switch). Another issue is: input on keyboard is also painfully slow, it freezes to seconds from time to time; the same with, say, clickling on YouTube video to pause playback — I could wait 3-5 seconds for the browser to get the event and use it. Surprisingly enough, I don't see the same degree of freezes while recording performance profiles rn.
https://share.firefox.dev/31RG7CX (tab switching)
https://share.firefox.dev/3iGzbyg (keyboard input)
Loom recording for tabs and inputs, as switching on profiler somehow didn't allow me to reproduce the issue fully:
https://www.loom.com/share/e20877dd2e6d412f8c8bc333b5ea0b71
Actual results:
Keyboard input is very slow, and so is tab switching: I'm working just as usual, but the inputs are delivered to the browser window with multi-second delay.
Expected results:
Tab switching and inputs works fast (about as fast as on previous browser versions)
|
||
Comment 1•5 years ago
|
||
Hmm, I don't see nothing particularly outrageous in that profile, but something is clearly going wrong from the video... Does this repro on a clean profile / safe mode? Also, does it repro on a Nightly build? (https://nightly.mozilla.org)
There seems to be some suspicious GC pauses in the "keyboard input", and also the network thread seems extremely busy doing requests to min-api.cryptocompare.com, and the twitter API... Not quite sure that's expected given the tabs that you may have opened and your extensions.
Another thing that may be useful to isolate what caused this is finding a regression range. It shouldn't take much if you have the time and a stable internet connection using mozregression. You can use mozregression --profile-persistence clone --profile /path/to/your/profile --good 77 --bad 78.
|
Reporter | |
Comment 2•5 years ago
|
||
Oh my, maybe I've caught a crypto miner. Deleted all the service workers, would need to take some time to see, whether that fixes the issue (for now I don't see those crazy lags). Thank you for pointing out the issue (crypto-whatever seems weird, as it's not a domain I've consciously visited for sure). Had to wrap my head to figure out where all the service workers 'live', but thakfully FF has the tab for this (about:debugging#/runtime/this-firefox)
|
|
Reporter | |
Comment 3•5 years ago
|
||
It just happened 'just in time' with the browser update, so I've thought that this could be the case. Sorry for interruption and many-many thanks for your help!
|
|
||
Comment 4•5 years ago
|
||
No worries, glad it works ok now! Perry, do you know if we have something in place to try to prevent abuses from service-workers from affecting the browser experience?
I'm thinking stuff like auto-limiting service-workers' CPU time or what not, but I'm not all that familiar with SW so I'm sure you'd know better :)
|
||
Comment 5•5 years ago
|
||
I'm surprised this didn't happen while the profiler was running. There should not be any way for service workers to detect whether they're being profiled.
|
|
Reporter | |
Comment 6•5 years ago
|
||
Just keeping you in loop, it may be that twitter ServiceWorker gets into loop or something — I was getting the same 'oh boy, nothing ever works' day after removing all the SWs. I use twitter, well, frequently, so this one got reinstalled. If I'll run into the same issue — will record a profile and send it here
|
||
Comment 7•5 years ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) (PTO until Jul 10) from comment #4)
No worries, glad it works ok now! Perry, do you know if we have something in place to try to prevent abuses from service-workers from affecting the browser experience?
I'm thinking stuff like auto-limiting service-workers' CPU time or what not, but I'm not all that familiar with SW so I'm sure you'd know better :)
Yeah, there is a builtin timer that forcefully will terminate a SW is any is behaving abnormally (i.e. taking too long to do something, maybe because it's mining bitcoin instead of responding to a network event). It's currently set to 30s, which I believe is consistent with the other browsers (who also have a similar mechanism). The mitigations could definitely be better though - there's no CPU limiting involved specifically for SWs. Anyhow, yeah if there's a "bad" SW it could potentially run for up to 30s, and this might keep happening each time the SW is executed (after being terminated).
|
|
Reporter | |
Comment 8•5 years ago
|
||
Hello! Sorry for bringing this one up one more time, but it may be that SWs aren't the main (or the only) issue I've got here. I've cleaned up all the SWs, but run into the same issue. Maybe it's twitter's SW (I'm thinking of it just because it was mentioned earlier in the thread), and maybe something else. Once more, it isn't as bad with profiler switched on, but I've done another loom just in case.
Profile
https://share.firefox.dev/2W7jgzv
Loom recording
https://www.loom.com/share/617e329e3bfd45c6b147f70fb86d83b7
|
|
||
Comment 9•5 years ago
|
||
Could you attach your about:support? Does it happen in safe mode / on a clean profile? Your network thread seems to be doing tons of stuff all the time which is pretty odd.
|
|
Reporter | |
Comment 10•5 years ago
|
||
|
|
Reporter | |
Comment 11•5 years ago
|
||
|
|
Reporter | |
Comment 12•5 years ago
|
||
|
|
Reporter | |
Comment 13•5 years ago
|
||
Oh, that's a bit surprising: upload of about info seemingly failed three times in a row, but looks like files are here! (btw, I've missed the upload file button on the top of the page). Clean mode works way faster, I'll go around and try to enable extensions one by one and see which one was causing the issues.
|
|
Reporter | |
Comment 14•5 years ago
|
||
Ok, I don't know, what's going on, but I've switched off all the extensions, browser started to work way better. Then I've switched extensions one-by-one, and — voila — it still works just fine. I'll get back if things would go sour once again (somehow I'm betting on it), but it's highly, well, surprising behavior. You've mentioned network thread being overworked, could you tell, please, what are the domains the most requests seem to be flying around? Maybe it'll help narrow the issue's scope a bit?
|
|
Reporter | |
Comment 15•5 years ago
|
||
Hey guys, just a little update. The browser works just fine, can't say what have caused all the havoc. I guess the issue could be closed, as it seems like there isn't long standing performance issue, and more of a unfortunate coincidence in one particular case.
|
|
||
Comment 16•5 years ago
|
||
Thanks for the update.
|
|
Reporter | |
Comment 17•5 years ago
|
||
Sorry for bringing this one up again, but the issue repeats, and I can't figure out why.
I've closed all the tabs, killed all the SWs (there are just the ones from websites I'm really using — read 'twitter')
New profile is here: https://share.firefox.dev/3fJSkgR It should have captured even keyboard input issue, and I've made another loom demo, so you could see what it looks like https://www.loom.com/share/d7245c34a4f3445cbba644d68d74ee9b
Could you tell, where could I look to figure out why the browser almost haltsafter ~1h of work? I've disabled all the extenstions, and then was switching them one-by-one with no any single one causing the effect. I don't see any high-power consumption tabs / processes in FF task manager, don't have suspicious service workres (and no running ones, if I am to believe about:debugging#/runtime/this-firefox page. This both puzzles me greatly and makes everyday things painful enough to bring the issue up from 'oh, everything seems fine state' where I'd wanted it to be forever.
|
||
Comment 18•5 years ago
|
||
This looks to me like long cycle-collection pauses in content process 84856. Something in that process has put a lot of objects into the heap, which is increasing the amount of things to traverse during the cycle-collection step.
I'd be interested in seeing an about:memory report when this state occurs to see if we can attribute the number of objects to a particular domain.
|
|
Reporter | |
Comment 19•5 years ago
|
||
Thank you for the directions! I've taken the report, it's in the attached file. How do you think, isn't any memory leak going to cause the issues like the one in this ticket?
|
|
||
Comment 20•5 years ago
|
||
There are ghost windows in that memory report - 5 on Twitter, 1 on YouTube. That might account for the long CC pauses while those windows have their objects traversed. Are you able to reproduce this issue with your WebExtensions disabled?
|
|
Reporter | |
Comment 21•5 years ago
|
||
https://share.firefox.dev/2WCEC8j — that's the one without extensions (safe mode)
|
||
Updated•3 years ago
|
Description
•