D8059: KDevelop: abstractfilemanagerimport benchmark

[René J.V. Bertin]

rjvbb added a comment.


  >   The number of calls to addDir is totally uninteresting. Even more so as before it was/is recursive internally while you are about to change it. So what value is there when the benchmark shows "1 call to addDir" now, and then eventually "1000 calls to addDir"?!
  >   
  >   Again: We only care about the time it takes to import the project.
  
  Please read me carefully. I DO care about more than time alone. If it takes 10 hours to add a quadrizillion directories I might be happy, but not if it takes 10 minutes to add only 5 directories (directory content shouldn't matter since we're watching only directories).
  
  Printing the number of directories loaded is only appropriate if we know that it corresponds to the exact number of directories watched. We don't know that here, there are 2 different models at play.
  
  Please don't try to teach me how to set up experiments (and I won't try to explain what the PS in FLOPS stand for).
  
  >   On Linux or on Mac?
  
  On both. I should have kept this information to my self, I've only been posting and comparing the stabilised scores anyway.
  
  >   So the issue for you is maybe that you are tracking the build folder as part of the project?
  
  The benchmark cannot exclude anything under the target directory, and the current dirwatcher implementation cannot either (it lets KDirWatch::addDir() do its recursive thing). Neither have filters set up.
  
  >   What happens when you move that build dir to a sibling folder?
  
  Load times decrease, evidently.
  
  I rarely use in-tree build dirs, so the build directory is NOT what is slowing things down under normal use.

REPOSITORY
  R32 KDevelop

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

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/20171023/893934df/attachment-0001.html>