GNOME Bugzilla – Bug 667456
gnome-shell becomes slow after a suspend/resume
Last modified: 2021-07-05 14:35:11 UTC
When you do a fresh boot, login and open a couple of windows, gnome-shell is very fluid and snappy. As soon as you put the computer to sleep however, you will notice that performance has degraded when you resume. This is particularly easy to notice on weaker graphic cards such as a r300, but I also see it on a radeon HD 2600 (r600 radeon gallium driver), on Fedora 15 and Fedora 16.
Example: http://jeff.ecchi.ca/public/mutter-667456.webm Of course, it's a bit hard to see as my camera only records at 23.976 frames per second, not 60+ fps. With the naked eye, it is much more obvious.
What version of mutter do you have?
3.2.1
mutter-3.6.0-112.2.x86_64 and Intel video. I haven't noticed any degredation over time. I'll deliberately suspend and resume a few times today and see if I can notice anything.
In my case I noticed a slow down especially in nautilus and gedit when scrolling. My scenario is a little different: when heavily using nautilus (using the tree view until deep in a folder structure, opening other tabs) and having large text files with syntax highlighting makes scrolling very slow. Restarting the shell (ALT+F2 r) of restarting the program fixes this for a few minutes. Also, bringing forward the activities overview has the same effect: scrolling goes from smooth to very choppy and back to smooth again after a (shell) restart. Other programs that do not rely on the gnome shell smooth scrolling are not affected by choppy scrolling performance (such as some Qt text editor I use for some of my Python work). At some point the performance increased a little bit by using two gnome-shell extensions: Disable Window Animations (https://extensions.gnome.org/extension/119/disable-window-animations/) and Impatience (https://extensions.gnome.org/extension/277/impatience/) by reducing the shell animation length to close to zero. But the latter is not giving any improvements any more these days. I would like to help with some additional debugging/performance testing, but got stuck. Are there any useful pointers I missed? I've found this entry: http://blog.fishsoup.net/2010/05/26/measuring-gnome-shell-performance/ and http://shell-perf.gnome.org but I am not sure if that post is still up to date (or maybe I just didn't get it) because the proposed method is not working as expected: $ gnome-shell --replace --perf=core gnome-shell: Unknown option --perf=core I am using gnome-shell 3.4.2, mutter 3.4.1 in Arch Linux 64bit with the latest binary blob NVidia drivers (304.51) on a NVidia Quadro NVS 160M
I see this slow down too. It is very tedious, and it happens each time I suspend my laptop. Gnome shell is unresponsive, slow. Nautilus has a strange behavior, since the columns of the list view continuously change their width, as they were trying adapt to some contents that does not exists... and also in the left panel, for example the line of removable devices blinks and the symbol for eject sometimes disappears and the label goes in the middle! The whole system is affected, since you can see the system very unresponsive also opening a terminal with ctrl+alt+f3. And now, while I am typing, if I press a key to repeat a letter, the letter is repeated for a while after I released the key! Gnome 3.6.4. Fedora 18. System updated, last kernel. Nvidia driver NVS 4200. Thank you Federico
While I reported this as early as 3.2, this problem persists even today with 3.10, on much much more powerful graphics hardware (this time a Radeon HD 7770 running the open-source radeonsi driver in Fedora 20). It's less dramatic than what you see on the video in the original description, given how insanely powerful my radeon 7770 is, but it's still noticeable. The reason why many developers don't run into this issue, I think, is because they're using Intel drivers, and for *some reason* the Intel hardware doesn't seem to be affected in a highly visible way by this. On all other graphic drivers I've seen however, the problem is quite noticeable. I just need to suspend the computer for the night, resume with my bunch of big windows (Firefox, Evolution, gedit, etc.) at 1920x1080, and notice how entering/exiting the gnome-shell overview animation feels slow. Reloading the shell by hitting alt+F2 and entering "r" fixes the issue... until the next suspend/resume cycle. It's as if gnome-shell was filling up some graphics memory with rubbish and not freeing it, or as if it was getting "off sync" with the painting/drawing clock...
I'm seeing this on 3.8 as well. Intel HD4000 driver. After resuming, the interface is unresponsive, and that gets worse as time goes on. I can confirm that memory consumption goes from 2.6% of my Memory to 15.3% eventually (after several hours), so a memory leak is suspect. It is fixed by restarting the shell, but returns on the next suspend/resume cycle. I'm sure if any of the developers are running on a laptop, they will see the issue after several suspend/resume cycles. It doesn't happen on every one. The easiest way to see it is by running a video. The video will have about 200 ms of pause for every 2 seconds of video or so. This is actually the entire windows manager freezing up. After a couple of hours it's perfectly evident on any application though.
Performance regresses over session lifetime even in 3.24 and Wayland on Intel (Haswell). Workspace switching and animations become noticeably more and more choppy. Restarting session is the only thing that helps. If OS X did this, Jobs would be rolling over in his grave. Perhaps related to https://bugzilla.gnome.org/show_bug.cgi?id=642652
Can confirm last comment, now wayland crash are fixed, I can't use Wayland session because over time, workspace switching is really slow...
Fixed in 3.28 for me
(In reply to Cédric Bellegarde from comment #11) > Fixed in 3.28 for me Maybe? Over at https://bugzilla.gnome.org/show_bug.cgi?id=745032#c99 an Arch Linux user reports still stuttery mouse movement, but impossible to tell if the same issue. I also added some general performance debugging process thoughts at https://bugzilla.gnome.org/show_bug.cgi?id=745032#c102 but Gentoo is still barely getting 3.26 into the main tree.. Not sure when I'll be able to test 3.28 for myself.
stuttery mouse movement will no be fixed until: https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4
> stuttery mouse movement will no be fixed until: Thanks for the link, I had indeed forgotten to read up on the upcoming GS4 effort. However, this document is talking about things at a whole different level - which *might* solve the same problem as well, but is highly likely way way down in the future, compared to fixing a bug in the current gnome-shell generation. Actually, for all I know, these options could both be equally far away in time. Either way, both this bug (titled "gnome-shell becomes slow"), and the linked one (title "mouse tracking laggy"), may be directly linked, hypothesis being that: "the eventual mouse stuttering experience is simply a result of the general slowness increasing over time, due to too much processing waste / garbage (of some x kind) piling up somewhere" Seems like a valid hypothesis, simply because everybody is reporting everything being silky smooth early in the session, even on current gnome-shell generation. Same here, small screen, big screen, whatever apps running, at first everything is fine and moves fast. Then after some x days of work, you start noticing the increasing jerkiness of the animations and small hangups in mouse cursor movement and in typing.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.