February 11, 2023, 10:35am
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
$ [-] 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
['firstname.lastname@example.org', 'ShellTile@emasab.it', 'audio-output-switcher@anduchs', 'audio-input-switcher@anduchs', 'GPaste@gnome-shell-extensions.gnome.org', 'email@example.com@posteo.de', 'firstname.lastname@example.org', 'TopIcons@phocean.net', 'email@example.com', 'firstname.lastname@example.org', 'email@example.com', 'firstname.lastname@example.org', 'email@example.com', 'firstname.lastname@example.org', 'email@example.com', 'firstname.lastname@example.org', 'email@example.com', 'firstname.lastname@example.org']
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?
February 11, 2023, 12:15pm
Why is this posted under the Evolution tag?
February 11, 2023, 12:26pm
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.
February 11, 2023, 2:32pm
Switch off all GNOME Shell extensions, reboot, and see if that changes anything.
February 11, 2023, 3:41pm
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.
February 11, 2023, 4:56pm
Which instrumentation makes sense to enable?
February 11, 2023, 5:14pm
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.
February 17, 2023, 3:13pm
Note that to use sysprof effectively you will need to have compiled all the binaries with
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
February 17, 2023, 3:41pm
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.
March 19, 2023, 3:41pm
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.