<table><tr><td style="">mwolff added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D9824" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D9824#193095" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D9824#193095</a>, <a href="https://phabricator.kde.org/p/dfaure/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@dfaure</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>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]...</p>

<p>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?</p></div>
</blockquote>

<p>Note that many other functions iterate over all entries in <tt style="background: #ebebeb; font-size: 13px;">m_mapEntries</tt>:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">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()</pre></div>

<p>This is why I claim that more situations can trigger high CPU load when the list is large.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R244 KCoreAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D9824" rel="noreferrer">https://phabricator.kde.org/D9824</a></div></div><br /><div><strong>To: </strong>mwolff, dfaure, KDevelop, markg, aaronpuchert<br /><strong>Cc: </strong>aaronpuchert, bcooksley, zimmerman, markg, Frameworks<br /></div>