Extension makes system borderline unresponsive on GNOME 45 wayland

[JohnTheCoolingFan]

Preamble

I'm using Gentoo and just swapped my cpu and was thinking that this swap caused the problems, but it appears it does not, I can reliably reproduce the problem and make it go away.

Technical information

Gentoo Linux, system updates checked and installed today.
CPU is Ryzen 7 5800X3D now, Ryzen 5 3600 previously (in case it matters somehow)
Launching gnome shell using GDM, regular GNOME 45 session on Wayland.
gnome-shell version 45.5, extension downloaded from extensions.gnome.org, version 57, installed manually into ~/.local/share/gnome-shell/extensions/ (due to a flatpak-related bug)

Description of the problem

On boot

Booting up, GDM works fine, but in the session the system lags a bit before going to the main screen, where it shows current desktops. typing anything won't do anything until 5-10 seconds pass. You can type and search your apps, but mouse pointer will not have any interactions, you are limited to the keyboard. Pressing Super (Win) key or Alt doesn't register, you can't bring up app menu or close a window with Alt+F4. Although these keys started working sometime during my package recompilation due to new cpu, but I did not measure the delay, which was huge.
In desktop/normal view, any non-primary screens will gray out, not displaying the current wallpaper. None of the GUI elements are intractable with the mouse pointer.
If you manage to disable the extension, the system becomes responsive again (or after a reboot)

When enabling the extension during normal operation

If I boot and log in with the extension disabled, the system works without any issues, but when I go and enable it, the system becomes nearly unresponsive again, I can still do some things using the mouse, like close the extensions manager window, but some special keyboard key presses stop being recognized. Also, the extension manager's window leaves a "ghost"/"imprint" when closed. Not a real window, but a snapshot of it stuck on the desktop. Requires a reboot to turn off or delete the extension.

Usually I solved this problem by booting up, logging in and opening a terminal, from which I can do all of the other stuff.

htop would also show a lot of processes named gnome-shell that use quite a bit of RAM.

This is all I know about this problem, it started appearing at weird circumstances and behaves weirdly, but enabling this extension is what causes it.

[JohnTheCoolingFan]

I really like the extension, but it has had numerous random issues during screen locking or something else. Never got around to testing out how reproducible it is, what the behavior is, etc. But this issue is very severe on my system.

[Tudmotu]

Hm, interesting issue. This extension has had many performance issues throughout the years so it's unsurprising some still exist.

One of the most common issues is when the history file becomes too large for GNOME to handle in-memory.

Can you try removing/renaming the cache file:

mv ~/.cache/[email protected]/registry.txt ~/.cache/[email protected]/registry.txt.backup

And see if that helps?

Thanks

[JohnTheCoolingFan]

Yes, that does solve the problem. It may be related to some of the images in clipboard having big size... The whole cache dir [email protected] takes up 71MB, with 4 of the files being over 10MB (images). I don't have any important stuff in there, so I will probably delete the backed up registry.txt
du -ahx --max-depth=1 | sort -h:

4,0K	./registry.txt
8,0K	./registry.txt.bak
200K	./1749080101
588K	./2190397565
740K	./1599510883
768K	./3780723999
1,3M	./3929520869
4,2M	./3847881769
8,7M	./1983884844
11M	./3172961440
12M	./3620114385
16M	./541356220
18M	./956252390
71M	.

[JohnTheCoolingFan]

I think there should be some protections against such problems. Like limiting the size of what gets loaded into memory or something else.

[mattia-b89]

I use Arch Linux and I have never had such kind of issue.
Is it still valid or has been fixed in the meantime?
How can I reproduce it?

[Tudmotu]

@mattia-b89 this depends a lot on the system of the user, what other extensions they have installed, etc. You can start by trying to copy many large hi-definition images or large UTF texts to your clipboard.

Unfortunately it's really difficult reproducing these performance issues.

[JohnTheCoolingFan]

After clearing the cache last time I have been using the extension without problems. I agree it is hard to reproduce and in my clipboard history big files probably get removed quickly as I copy a lot of stuff (especially when using neovim with system clipboard by default).
I guess an "easy" way to reproduce is copy large files into the clipboard (the data itself and not just references by path), or large text portions, over 2k characters. This is just a guess based on the causes and behavior of the problem.