This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Don't build diagnostics when preparing AST for a normal action.
Needs ReviewPublic

Authored by sammccall on Jun 3 2020, 2:00 AM.

Details

Reviewers
kadircet
Summary

This saves something like 20% latency on the AST build with a typical load of
clang-tidy checks.
The tradeoff is the AST is never cached for diagnostics, but this is less
latency sensitive and rarely happens anyway.

Diff Detail

Event Timeline

sammccall created this revision.Jun 3 2020, 2:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2020, 2:00 AM
kadircet added inline comments.Jun 3 2020, 4:01 AM
clang-tools-extra/clangd/ParsedAST.cpp
370

while here, maybe introduce another span for include fixer initialization ?

as getFormatStyle can do IO

375

umm, actually this is wrong in presence of stale preambles ... we should perform patching before initializing include fixer and make use of patched includes rather than stale ones.

no action needing, just taking a note for myself.

435

maybe

if (ProduceDiagnostics) {
 assert(CTFinder.hasValue());
...
}

to keep it similar to other usages.

clang-tools-extra/clangd/TUScheduler.h
112

why don't we just drop this ? I believe this patch is doing 2 things:

  • Don't build diagnostics for read operations
  • Don't reuse cached asts for diagnostics

and I think getting rid of ReuseAST bit would belong to second one. (unless we decide to emit status while building asts for read operations)

clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
470

nit: initialize to false

clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
540

WantDiags::Auto should be enough here, as we are blocking afterwards. I've heard someone is tryin to get rid of those :P

546

again WantDiags::Auto should do for both

796

is it worth asserting here (or in a new test) that AST.diags() is empty, whereas it is non-empty below ? (ofc, after introducing some diags to the code)

sammccall marked 8 inline comments as done.Jun 3 2020, 7:13 AM

rarely happens anyway

citation needed.

While this is true today, it seems fairly likely that async preambles is going to flip the dominant AST reuse from diagnostics -> read to read -> diagnostics.

This change would make the builds 20% faster for the cache misses on AST read (~30%), at the cost of rebuilding when diagnostics would hit (~0%).
If those probabilities flip, this becomes a really bad trade.

Let's wait a couple of weeks until we have data from production.

clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
796

I don't think we want to *guarantee* when they're present/absent with runWithAST, this is an implementation choice. Added a comment to make this contract explicit.

sammccall updated this revision to Diff 268188.Jun 3 2020, 7:13 AM
sammccall marked an inline comment as done.

address comments