https://bugs.kde.org/show_bug.cgi?id=488205
--- Comment #8 from Vaclav Fiala <f...@fedy.cz> --- > When we don't have solid info it's based on matching Exec lines with desktop > files. That's all cached, so relatively fast, but it's doing something with > symlink evaluation in there. Yes, something seems to be messed-up in this evaluation. The issue might no even be part of kwin itself but some foundational KDE library (i.e. /usr/lib64/libKF6Service.so.6.2.0). I used the stack trace to look-up the problematic code but didn't get very far (the functions/methods mostly lack documentations so I was only guessing their purpose and I'm not familiar with the codebase). Looking up the binary in a home dir is (almost) guaranteed to fail & also it's probably performed __ instead of __ the correct binary path. Also wl-clipboard rpm package (containing wl-paste) doesn't include any .desktop files, so maybe some optimizations could be made / or it might be a part of the issue? > > It's not slow because of clipboard access, it's slow determining whether > wl-paste is told there's an interface to move it's window / etc. I wasn't trying to suggest the core issue is the clipboard handling. Just discovered a weird behavior and this is (so far) the only reliable way to replicate it I found. I know invoking wl-paste repeatedly isn't very efficient (the scripts are more general and can also use xclip which doesn't have the --watch mode) , but that is not the point here. The CPU spike is in kwin, the related traces are weird, quite obviously buggy, and in my opinion worth investigating (regardless if it will lead to performance improvement in the end). -- You are receiving this mail because: You are watching all bug changes.
