https://bugs.kde.org/show_bug.cgi?id=470026
--- Comment #6 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- (In reply to Méven from comment #5) > (In reply to Adam Fontenot from comment #4) > > I'm changing the title and moving this to reflect the generic nature of what > > I take the issue to be. > > > > Adding two "see also" links. There is an existing confirmed report that > > *adding* an entry to the recently used list adds ~100 ms latency to the > > application calling the KRecentDocument function. There's another confirmed > > report related to the privacy issue I mentioned in a comment above: KDE adds > > items to recently-used even when this is disabled in the settings. > > > > I think *this* issue is about kactivitymanagerd using inotify on > > recently-used.xbel and parsing it whenever the file is updated. This doesn't > > add latency to operations like the other issue, but it can consume even more > > CPU time (claiming a full core in this case) because it seems to reparse the > > whole file whenever it changes. > > Unfortunately to do its, it has too, but it maintains a 500 files limit in > the file to cap the time it spends in parsing. > > We could simply disable the inotify watch or the parsing when the history is > turned off indeed. > But an optimization already would be to throttle the inotify events: limit > them to 1 every 10ms for instance would be a sufficient optimization already. Is the 500 file limit new? When I reported this back in 2023, I noted at the time that the file had about 1000 entries. As to throttling, is there a way I could benchmark the performance? Back in 2023 when this issue first came up for me, it appears that downloading a single file every few seconds was enough to peg the core to 100%, so limiting it to 1 every 10 ms wouldn't even be close to enough. Of course this was with 1000 files and maybe the performance has been improved since then. Does kactivitymanagerd ignore inotify events triggered while it is currently processing due to a previous event? If not then one issue here (which might explain the consistent 100% CPU usage) would be that the work stacks up during periods when many files are added, and kactivitymanagerd doesn't catch up until whatever is adding recent files has finished doing so. -- You are receiving this mail because: You are watching all bug changes.
