https://bugs.kde.org/show_bug.cgi?id=470026
Michael <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om --- Comment #7 from Michael <[email protected]> --- (In reply to Adam Fontenot from comment #2) > (In reply to Nate Graham from comment #1) > > Hi Adam! Sorry we were not able to get to this yet. Can you still reproduce > > the issue in Plasma 6.3.4 or later? Thanks a lot! > > even saving a single file causes > kactivitymanagerd to noticeably spike. I had the exact same issue and was pulling out my hair wondering why this was happening in Plasma 6.3.x. I've fixed this (see below) and have no issues in 6.4.4. > However, I think this issue might be caused by the file picker. When I click > save, it's appears to be the *portal* that is updating > ~/.local/share/recently-used.xbel, and kactivitymanagerd then reads / parses > this file, and that's the CPU activity I see. (Both the default Firefox file > picker and the KDE xdg-desktop-portal one seem to trigger this.) The issue > doesn't seem to be the result of the download itself - I see the CPU > activity even if the file fails to download. It even happens when you simply *run* a program, like Spectacle, and even from the commandline, which is something I do a lot. Like a lot. > I tried the most obvious thing I could think of, which was to disable the > "recent files / remember opened documents" option in system settings. > However, I ran into an issue that was rather disturbing - neither disabling > the option nor *explicitly* clearing the history ("forget everything") > deleted the contents of the file recently-used.xbel nor did they affect the > behavior of this issue. Am I misunderstanding what these settings are > supposed to do, or is this a bug that I need to report separately? I tried that too, and was dismayed that neither solved the issue. It wasn't until I found this bug report that I was able to learn that my ~/.local/share/recently-used.xbel file was 11MB(!) and that was the cause of the slowdown, processing that. I do a lot of automated work and even with the Settings -> Recent Files -> Keep history -> For 1 month, the file was 11MB of XML data. > Manually deleting the recently-used.xbel file knocked the CPU time used by > kactivitymanagerd down to almost nothing, indicating that parsing this file > (which could get very large if history pruning is not enabled or is broken) > is probably responsible for the issue. That worked for me. By renaming recently-used.xbel to .old and letting the file start fresh, the problem instantly went away. No more kactivitymanagerd pegging a CPU core at 100% and turning on my fans. It would be great to have a safeguard in place that checks for an overly large ~/.local/share/recently-used.xbel and if so, trims it down or deletes it, as it's useless if it's in the giant 11MB range that I found mine to be. Or at least fix the System Settings -> Recent Files -> Clear History -> Forget Everything functionality. When I invoke that, it doesn't eliminate recently-used.xbel. Nor changing the "Remember opened documents" setting to "Do not remember". Curiously, under Plasma 6.4.4, I have Keep history set to 1 month, yet it's keeping the recently-used.xbel file small at 192KB and only saving 2 days worth of entries. So something is working right, but I had to essentially delete recently-used.xbel first before it could right itself. -- You are receiving this mail because: You are watching all bug changes.
