TopHat causes composition stuttering when updating (Wayland)

[asumagic]

I installed TopHat recently and noticed that I lose compositor frames whenever TopHat updates, even when at a 60Hz refresh rate. This does not reproduce when I disable the entire extension.
That stuttering however reproduces even if I disable every display option in the settings (i.e. no monitor is actually shown), so I cannot pinpoint it to anything in particular.

I'm using the latest TopHat version on GNOME 44.4 on Wayland, under Arch Linux. Some other miscellaneous details, as those involve things TopHat might be trying to monitor: my CPU is a 3900X (24 threads) and I have 6 ZFS datasets mounted.

I profiled the system using Sysprof while keeping glxgears on to make sure that there was something to composite, and filtered to a moment when stuttering occurs:

My guess is that the extension is doing too much work synchronously (though I don't know if it can do otherwise), which given GNOME's... curious composition and extension model causes the entire compositor to stutter.

[fflewddur]

Thanks for reporting this! Does the stuttering still occur if you disable animations in TopHat's preferences? I'm not too happy with the current state of the animation code anyway, and suspect that might be the issue here.

[asumagic]

It doesn't seem to be caused by animations, I still encounter the same stutters with these settings:

Also, __open/__read/__close being high up in the trace is probably because of poking at sysfs. Looking at the strace of the gnome-shell process seems to corroborate this as I can see TopHat walks through all of /proc (even when the CPU widget is disabled).

I'm curious if this reproduces on other machines. If so then maybe refreshing the process list only when opening the CPU view would save a bit of CPU and power at the cost of delaying the process view.