D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry

[Milian Wolff]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180122/30c7c146/attachment.html>