Gnome-shell-43.2: render performance slowly but continously degrades, how to debug?

[lkraav (Leho K)]

Hi all

OS / Hardware context

$ [-] uname -a
Linux papaya 6.0.18-gentoo+ #73 SMP PREEMPT_DYNAMIC Tue Jan 10 10:42:01 EET 2023 x86_64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz GenuineIntel GNU/Linux

$ [-] cat /etc/environment
LIBVA_DRIVER_NAME=iHD
MESA_LOADER_DRIVER_OVERRIDE=iris

$ [-] qlist -IU mesa
media-libs/mesa X abi_x86_64 cpu_flags_x86_sse2 gles2 proprietary-codecs video_cards_intel wayland zstd
x11-apps/mesa-progs X abi_x86_64 wayland

$ [-] gsettings get org.gnome.shell enabled-extensions
['battery_status@milliburn.github.com', 'ShellTile@emasab.it', 'audio-output-switcher@anduchs', 'audio-input-switcher@anduchs', 'GPaste@gnome-shell-extensions.gnome.org', 'syncthingicon@jay.strict@posteo.de', 'switcher@landau.fi', 'TopIcons@phocean.net', 'transparent-window@pbxqdown.github.com', 'places-menu@gnome-shell-extensions.gcampax.github.com', 'sound-output-device-chooser@kgshank.net', 'workspace-indicator@gnome-shell-extensions.gcampax.github.com', 'window-list@gnome-shell-extensions.gcampax.github.com', 'pomodoro@arun.codito.in', 'auto-move-windows@gnome-shell-extensions.gcampax.github.com', 'impatience@gfxmonk.net', 'noannoyance@daase.net', 'tophat@fflewddur.github.io']

Problem
In my software developer role, I admit, I load this workstation heavy, every day.

• Large displays (4k, 5k2k)
• Video calls through every day
• High heavy open app count (Firefox, Chrome, PhpStorm / IntelliJ (Java), Slack, Discord, Mattermost (lots of Electron); Terminal, Evolution (multiple windows) - 32G RAM was def. the right choice)

After a fresh login, everything is quite nice and smooth for a while, even after I load up majority of the workload apps.

But as days go by, Shell starts to become increasingly laggy.

• Cursor movement starts stuttering here and there, but does so consistently.
• All kinds of UI elements react slower.
• htop shows gnome-shell consuming even 10% of memory (this is 3+GB here!) - signs of memory leaks.
• I am aware running into swap can cause this, too - but I’m fairly certain this degraded experience is not only about active swapping operations, since such happens fairly rarely.

What can I do to retain the initial session smoothness longer?
What are some debug techniques I can use to provide more data here?

[poc (Patrick O'Callaghan)]

Why is this posted under the Evolution tag?

[jakedane]

@poc

Why is this posted under the Evolution tag?

I’ve removed it. Evolution is mentioned as one of the “heavy apps” so maybe because of that. Let’s get Evolution involved if it turns out that app is the cause.

[andre (Andre Klapper)]

@lkraav

What can I do to retain the initial session smoothness longer?
What are some debug techniques I can use to provide more data here?

Switch off all GNOME Shell extensions, reboot, and see if that changes anything.

[jadahl (Jonas Ådahl)]

@lkraav

What are some debug techniques I can use to provide more data here?

If there are specific things that have started to become slower, you can try using Sysprof to record a short period of time (e.g. 10-20 second), and then investigate by looking into the “instruments” part of the resulting trace. It’ll contain information about every frame painted, e.g. when they were painted, what part took more time. It doesn’t, however, show you how much time is spent by e.g. extensions doing their things, but sometimes it can give you a hint of what is going on.

[lkraav (Leho K)]

Which instrumentation makes sense to enable?

[jadahl (Jonas Ådahl)]

@lkraav

Which instrumentation makes sense to enable?

The “GNOME Shell” (top right icon) one is what I meant. Later when viewing the recording, there will be a “Timings” view which will contain information about what happens on the main thread over time.

[alatiera (Jordan Petridis)]

Note that to use sysprof effectively you will need to have compiled all the binaries with -fno-omit-frame-pointerin CFLAGS. It’s unlikely the flag is part of the default set distros are using so do double check.

Also here’s a brief documentation page for sysprof

Sysprof

[jadahl (Jonas Ådahl)]

The “Timings” view in sysprof does not make use of frame pointers, it depends on instrumentation manually added and built into the executable, either by using explicit start/stop markers, or C extension semantics for scope based execution handling, relying on querying the monotonic clock and streaming timings to sysprof.