D8059: KDevelop: abstractfilemanagerimport benchmark

René J.V. Bertin noreply at phabricator.kde.org
Fri Oct 27 17:26:43 UTC 2017

rjvbb added a comment.

  So, where do we go from here?
  I started preparing the introduction of the ProjectWatcher class (which was rejected from the benchmark introduction patch) but then realised that it isn't justified as a standalone commit. That class only makes sense if you're going to use it other than by handing the project top dir to ProjectWatcher::addDir, telling it to add everything under that directory.
  The class makes sense as part of my patch that lets FileManagerListJob determine which directories (dirs only!) get watched, and it's with that use pattern that it makes sense to check if the directory trips a filter.
  IOW, I'm not in favour of going through a review just to introduce a ProjectWatcher class knowing it does things (like locking a mutex) that are superfluous in the current context.
  As to checking the project filter in ProjectWatcher::addDir() : it seems obvious that this *must* have a significant benefit under the right conditions (in-tree build dir and/or the .git directory for projects with a matching exclusion filter). Is it really necessary to go through an additional review just to add the filter check?

  R32 KDevelop


To: rjvbb, #kdevelop, mwolff
Cc: mwolff, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171027/363e5694/attachment-0001.html>

More information about the KDevelop-devel mailing list