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?
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.
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.
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.
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
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.
