D18551: clang: Create preamble only on second parse
noreply at phabricator.kde.org
Mon Feb 11 22:48:07 GMT 2019
aaronpuchert added a comment.
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.
> 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.
> 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.
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 all every time the header is changed. So the user will always get in situations where the preamble is not be immediately available. Unless we guarantee that however, using the flag is purely window-dressing.
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...
More information about the KDevelop-devel