mwolff added a comment.
In https://phabricator.kde.org/D9824#193095, @dfaure wrote: > This patch fixes a O(n) performance issue in the inotify backend using a cache, which makes KDirWatch *better* suited for applications that use KDirWatch heavily. Clearly a step in the right direction. Yes a cache needs memory, like all caches, how else is one going to optimize linear searches [in unsorted data]... > > I looked at whether other backends have a similar linear search, and only KDirWatchPrivate::checkFAMEvent has something similar, so FAM could use a cache where the key would be the "request number" as obtained with FAMREQUEST_GETREQNUM. That's a different patch though. The other backends don't have such a linear search, why are we even talking of "doing the same for the QSFW backend"? That's not applicable. How about taking a look at the code before requesting to optimize linear searches that don't exist? Note that many other functions iterate over all entries in `m_mapEntries`: void KDirWatchPrivate::removeEntries(KDirWatch *instance) void KDirWatchPrivate::stopScan(KDirWatch *instance) void KDirWatchPrivate::startScan(KDirWatch *instance, bool notify, bool skippedToo) void KDirWatchPrivate::resetList(KDirWatch *instance, bool skippedToo) void KDirWatchPrivate::slotRescan() // twice even! void KDirWatchPrivate::famEventReceived() void KDirWatchPrivate::checkFAMEvent(FAMEvent *fe) void KDirWatchPrivate::statistics() This is why I claim that more situations can trigger high CPU load when the list is large. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D9824 To: mwolff, dfaure, #kdevelop, markg, aaronpuchert Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks
