D18551: clang: Create preamble only on second parse

Milian Wolff noreply at phabricator.kde.org
Fri Feb 15 09:35:51 GMT 2019

mwolff added a comment.

  In D18551#410223 <https://phabricator.kde.org/D18551#410223>, @aaronpuchert wrote:
  > In D18551#409551 <https://phabricator.kde.org/D18551#409551>, @mwolff wrote:
  > > When we didn't create the preamble, we will have to reparse the file completely. And this can easily take 1-2s per file, which is *really* annoying.
  > It only happens on the very first edit though, and will only be noticeable if code completion is required immediately after starting to edit the file. All following parses and code completions can use the precompiled preamble then. I don't think that's too bad. It's also not unusual, many applications have something like a "warmup phase" where not everything is loaded yet.
  Yes, but hiding or minimizing the warmup phase is good. And it would be possible by having the flag active for opened files like I request.
  >> Also note how we just reparsed the file solely for code completion purposes!
  > You mean the preamble? Since code completion is usually invoked after some initial changes, we have to reparse anyway. What you said would only be true if we invoke code completion without changing anything first, which seems rather weird.
  I mean: We trigger a reparse when we open a document, to get hold of the clang TU to do code completion. If this *does not* create a preamble, then the following call to query code completion items - *after* editing - will create the preamble. The preamble only includes the headers of the file, not the contents of the `.cpp`. You usually edit the `.cpp` file and then you want to get code completion results immediately. Having a preamble is crucial for good performance here.
  >> So I really am opposed to the idea of never passing `CXTranslationUnit_CreatePreambleOnFirstParse`. Please, do create the preamble when we have the TU main file or its header file open in the editor.
  > For all open files, or just the ones that are active? My point is that we will probably not get to a point where we can guarantee that we have preambles for all open files around, so why bother at all? Preambles are there to speed up repeated reparsing, so I think we should only keep them for files where that is actually the case, meaning that they are actively changed.
  Lacking an proper LRU cache, enabling it for all open documents is the only option we have currently I think.
  > Anything beyond that would put enormous strain on the user's resources. Imagine someone editing a header that is used in other open files. We don't want to immediately reparse them every time the header is changed. So the user will always get in situations where the preamble is not immediately available. Unless we guarantee that however, using the flag is purely window-dressing.
  The reparse would only happen when we trigger a new parse job. Which we - afaik - only do on activation.

  R32 KDevelop


To: aaronpuchert, #kdevelop, mwolff, brauch, rjvbb
Cc: rjvbb, kdevelop-devel, gennad, glebaccon, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190215/2678e818/attachment-0001.html>

More information about the KDevelop-devel mailing list