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

David Faure noreply at phabricator.kde.org
Fri Jan 19 08:33:37 UTC 2018


dfaure added a comment.


  In https://phabricator.kde.org/D9824#193179, @rjvbb wrote:
  
  > > That's not applicable.
  >
  > Did you read my actual, original request? If so you'd have seen that it's satisfied by this answer.
  
  
  Then why didn't you open kdirwatch.cpp yourself to look for m_mapEntries.constBegin() like I did? It's not rocket science, and it would have moved the discussion forward.
  
  > Also please note the final remark in the author's summary, `Note that the other backends could leverage a similar trick to speed them up.`
  
  Correct for FAM.
  Doesn't turn out to be the case for the other backends.
  
  >>   The benchmark is not synthetic, it measures exactly the use case of monitoring a large number of files and touching them all (like `git checkout anotherbranch` would do).
  > 
  > What's the use of an application that watches the amount of files we're talking about here for changes with which it does nothing, other than benchmarking or unit-testing? We don't know how many files we're talking about here (the benchmark results only show the total amount of CPU cycles spent). I suppose it must be a really large number if walking the list takes 7 minutes. I'm pretty certain that simultaneous change of only a fraction of that number of files will cause a very significant CPU load when KDevelop starts clang-parsing them all.
  
  clang-parsing is outside of KDirWatch's responsibilities. The point of all this is to make KDirWatch itself faster, isn't it? I thought you found it slow yourself, surely you can't object to Milian working on making it faster, whatever else the applications do after a change notification...

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D9824

To: mwolff, dfaure, rjvbb, #kdevelop, markg
Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180119/85ed2eef/attachment.html>


More information about the Kde-frameworks-devel mailing list