<table><tr><td style="">dfaure accepted this revision.<br />dfaure 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><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>

<p>The benchmark is not synthetic, it measures exactly the use case of monitoring a large number of files and touching them all (like <tt style="background: #ebebeb; font-size: 13px;">git checkout anotherbranch</tt> would do).</p>

<p>+2 from me.</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, rjvbb, KDevelop, markg<br /><strong>Cc: </strong>aaronpuchert, bcooksley, zimmerman, markg, Frameworks<br /></div>