Closed Bug 1294953 Opened 3 years ago Closed 3 years ago
.0a2 gets laggy after a while of usage .
Everything is slow to interact. Scrolling hangs, Firefox UI elements pops up with significant delay. Typing text is slow. I mean everything draws with a delay. It makes FF unusable. The only workaround is to restart browser and have few minutes of lag free browsing. Important thing to note is that the slowness is gradually increasing with the time FF is open. After few minutes or so I get slight hitching when scrolling, but it gets worst and worst and after few more minutes it gets almost unusable. I've narrowed it down to the v50 upgrade. This build works and is buttery smooth no matter how long Firefox is ruining. revision fcdf4bb703567bca5a5d7065f3a8a35ce1dea9ff and firefox-49.0a2.pl.win64 downloaded from: https://ftp.mozilla.org/pub/firefox/nightly/2016/08/2016-08-01-00-40-02-mozilla-aurora-l10n/ After upgrade to this the problem appears and is present also in latest aurora build. revision fcdf4bb703567bca5a5d7065f3a8a35ce1dea9ff and firefox-50.0a2.pl.win64 downloaded from: https://ftp.mozilla.org/pub/firefox/nightly/2016/08/2016-08-01-08-55-19-mozilla-aurora-l10n/ I've only tested on Windows 10 and x86_64 FF build. I tested with clean profile and the result is the same so it is not add-on issue or anything. Enabling/disabling E10S doesn't change anything. I've also monitored resource usage, nothing out of ordinary. CPU, GPU and memory usage looks normal. I'm currently on v49 because of this issue. Hope we can figure it out. Tell me what more information you need. Regards, Kacper
Edit: Not working rev is 70ee99f185b48cb59a4ec701282bf6a3fd6ce3e3... Copy paste error.
This or something similar is happening on Vista x86, too. Address space looks to be getting seriously fragmented. Perhaps the same as Bug 1293965, Bug 1293060 and/or Bug 1294653? I have a lot of tabs in several windows, but this something new in the last few days and happens over a period of hours, even if I'm only touching a relatively small proportion of my tabs. I have four content processes, in case it matters.
I think it is the same as Bug 1294653 (I missed this one). But for me even if I close all tabs and force GC in about:memory it is still slow.
Hi Kacper, Thanks for reporting this bug. Can you go to the about:support page and send us your information? Thanks!
Attached as text.txt. Not sure how this is helpful except my GPU information but here you have it :)
I spend some time with nightly builds and mozreggression tool which is great by the way. Bisecting on those massive slow downs is hard because they starts after some time depending on browser usage and I haven't managed to produce easy steps to reproduce the issue (with almost not responsive browser) fast. But I have found steps to quickly diagnose micro shuttering during scrolling on very big site. I spend quite some time to actually find the patch which broke it. I believe this is the same issue actually which gets more significant over time. Long story short, this commit is responsible for regression. https://hg.mozilla.org/mozilla-central/rev/445065352cf082627b3865c08dfe32ca328cb3ec And it seems like it is already being worked on in Bug 1295214. I will do some more testing to be sure and mark this bug report as a duplicate tomorrow.
I'm marking this as a duplicate since in Bug 1295214 there is already working patch. Looks like my report wasn't good enough because no one gets interested even tho it was before the other one :)
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1295214
Thank you for your work! :) Unfortunately, oftentimes you have to find the regressing bug, and let the original author know, before it gets enough attention. But now you have mozreggression, finding the regressing bug should be much easier :)
You need to log in before you can comment on or make changes to this bug.