D8059: KDevelop: abstractfilemanagerimport benchmark

[Milian Wolff]

mwolff added a comment.


  In https://phabricator.kde.org/D8059#159018, @rjvbb wrote:
  
  > >   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).
  
  
  Your experiment is pointless, so of course I'll teach you. I won't accept the patch as-is, so would you rather I just say no without giving an explanation?
  
  One more try in teaching you how this is supposed to be used:
  
  1. run benchmark with `perf stat -r 5` on a predefined folder structure, let's say GCC source dir, remember the output, this is your baseline
  2. apply a patch that supposedly optimizes something (e.g. apply the filter before watching a dir)
  3. rerun the benchmark on the same folder, again with `perf stat -r 5`
  4. compare the output of the two `perf stat` runs.
  
  Since the benchmark input (e.g. GCC source dir) does not change in between, the number of dirs is not interesting at all. We only care about whether the import after applying the patch is faster or not. All of this information would then be put into the commit message of the patch and then pushed up for review, along with all information that is required for someone else to reproduce the test.
  
  >>   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.
  
  What is a stabilised score?
  
  >>   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.
  
  The point is: I don't have the build dir as part of the project, so maybe that's why it's so much faster for me?
  
  >>   What happens when you move that build dir to a sibling folder?
  > 
  > Load times decrease, evidently.
  
  By how much?
  
  > 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/d3c059e7/attachment.html>