D7745: KDevelop (full) project parsing: defer until all projects have been loaded.

René J.V. Bertin noreply at phabricator.kde.org
Sat Sep 16 12:02:14 UTC 2017


rjvbb added a comment.


  >   Rene, maybe you want to look into this?
  
  This sounds like it could well be something requiring a substantially deeper understanding of the underlying architecture than I have (and wouldn't normally seek out just for fun ;))
  
  > " When doing this synchronously as a test, it takes maybe half a second instead of 30 seconds."
  
  This sounds like something that's independent of whether or not cmake server mode is used. If so, where does the 4x cmake server mode overhead I'm seeing come from?
  
  > "it lists all the build dirs"
  
  Who/what is "it" here? Can you confirm (or check) if this also happens for an out-of-tree build dir?
  
  > see comments on https://phabricator.kde.org/D7745 for why it's actually slow
  
  Which ones?
  
  As to not deferring: I continue to think it makes sense and will also make it a lot easier to isolate performance issues in the future, if/when we have addressed the current ones. As far as my timing results indicate (in the 5.1 branch), deferring doesn't change the total import time significantly under optimum conditions. It wasn't actually meant to do that either, the main goal was to hog the main event loop for as little time as possible during an import.
  As to making dirwatching optional: I agree the ideal solution would be to fix the feature (to remove the argument "don't waste cycles on something when it doesn't work anyway") but I'm not convinced it can be improved to the point where it takes a negligible amount of time on all platforms. Need I repeat that the main issue that triggered this diff was the fact I had to wait for minutes with the main thread running at 100% CPU outside the event loop?
  
  Seriously, how many of us use KDevelop to work on projects the size of GCC or llvm and need dirwatching on the whole tree? How expensive is that on Linux, *after* the initial import?
  
  Maybe the proposed checkbox to en/disable dirwatching should be coupled with a project-level per-directory setting, "watch this directory for changes", hidden simply (?) in the directory context menu and/or the "project filter" settings.
  
  Come to think of it, this is really something that can be compared to mail folder synchronisation. In KMail you can indicate for each folder if it has to be included in the scheduled email check (the version I use supports IMAP IDLE only on the inbox), but a sync will be performed each time to select a folder. In KDevelop this could be coupled to directory expansion in the project manager. I don't know if that's doable API-wise, but I like the idea, it sounds a lot quicker than doing a right-click and selecting the "Reload" action.
  
  R.

REPOSITORY
  R32 KDevelop

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

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


More information about the KDevelop-devel mailing list