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

[René J.V. Bertin]

rjvbb added a comment.


  David Faure wrote on 20180119::08:33:32 re: "https://phabricator.kde.org/D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry"
  
  >   Then why didn't you open XXX yourself to look for XXX like I did? It's not rocket science, and it would have moved the discussion forward.
  
  From previous experience the local culture is that a patch author explains why s/he does things and not certain other things (when asked). I don't always appreciate that when I'm the author but recognise that it's not an unreasonable principle.
  
  >   Correct for FAM.
  >   Doesn't turn out to be the case for the other backends.
  
  It should not have taken the OA long to establish this (me undoubtedly much longer).
  As he's likely to say himself: "Don't assume, measure".
  
  >   clang-parsing is outside of KDirWatch's responsibilities. The point of all this is to make KDirWatch itself faster, isn't it?
  
  Yeah, and there's a hole in my bucket ... If this makes KDW faster in ways that you can hardly measure under normal use there was little point even to ask for a review.
  
  Seriously, if something as simple as walking a list takes 7 minutes, how long would doing something (undoubtedly more time consuming) with all those file take? That's not a reason NOT to do (micro) optimisations, of course (but maybe a reason not to treat it as something spectacular).
  
  >   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...
  
  Of course, but I wonder why I'm still getting tricked in replying if my actual points aren't being read. What is slow in my experience is feeding a KDW instance. In every other experience I have with runtime behaviour and reaction to file changes the bottleneck is not KDW but whatever happens downstream.
  
  That's another reason why I haven't jumped in; I don't use any application where reaction time to filesystem changes is critical (or even too long to my taste). And if I did I'd be looking at cutting out layers between my code and the notification source.

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/4e9a5ad1/attachment-0001.html>