Repository navigation
clang-tidy check misc-unused-using-decls appears to be quite slow #72300
Description
The misc-unused-using-decls check constantly comes up as one of the top 3 expensive checks in our code base (it usually takes about 5% of the total time). Considering it is not providing that much in terms of its findings compared to other checks it seems a bit excessive.
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
0.8125 ( 11.9%) 0.0000 ( 0.0%) 0.8125 ( 7.4%) 0.7912 ( 7.2%) bugprone-reserved-identifier
0.4531 ( 6.6%) 0.3125 ( 7.6%) 0.7656 ( 7.0%) 0.6002 ( 5.5%) misc-unused-using-decls
0.2344 ( 3.4%) 0.0938 ( 2.3%) 0.3281 ( 3.0%) 0.4317 ( 3.9%) bugprone-use-after-move
0.7969 ( 11.6%) 0.0312 ( 0.8%) 0.8281 ( 7.5%) 0.8204 ( 7.5%) bugprone-reserved-identifier
0.2969 ( 4.3%) 0.3125 ( 7.7%) 0.6094 ( 5.6%) 0.6044 ( 5.5%) misc-unused-using-decls
0.4219 ( 6.1%) 0.1094 ( 2.7%) 0.5312 ( 4.8%) 0.4172 ( 3.8%) bugprone-use-after-move
0.5781 ( 5.0%) 0.4688 ( 4.9%) 1.0469 ( 5.0%) 1.1171 ( 5.3%) misc-unused-using-decls
0.8750 ( 7.6%) 0.0938 ( 1.0%) 0.9688 ( 4.6%) 0.9738 ( 4.6%) bugprone-reserved-identifier
0.7969 ( 6.9%) 0.2344 ( 2.5%) 1.0312 ( 4.9%) 0.8989 ( 4.3%) bugprone-use-after-move
Activity
sean-mcmanus commentedon Nov 14, 2023
@firewave Our team saw the same issue with our project (so we disabled that check in certain scenarios).
PiotrZSL commentedon Nov 14, 2023
That's on LLVM 17/18 ? Based on how this check is implemented, yes it can be slow & buggy. I will see what I can do.
sean-mcmanus commentedon Nov 14, 2023
@PiotrZSL I used clang-tidy 17.0.2.
firewave commentedon Nov 14, 2023
My numbers are from LLVM 18.
firewave commentedon Jan 24, 2024
Looks like this was fixed by #78231.
CC @HerrCai0907
HerrCai0907 commentedon Jan 24, 2024
@firewave Could you re-benchmark with current version?
firewave commentedon Jan 24, 2024
I am still seeing this:
I am using the binaries from
apt.llvm.shand the commit hash in the version indicates that the changes are included.Ubuntu clang version 18.0.0 (++20240123053045+8ed1291d96ea-1~exp1~20240123173204.910)It looks like it is the wrong version but
apt.llvm.shhas not yet been adjusted for the version bump. That usually takes a few days.PiotrZSL commentedon Jan 24, 2024
800ms for a clang-tidy check is not much, depend on file size.
firewave commentedon Jan 24, 2024
You sure? If you would have 100 of such checks a single file would take 80000ms. But we digress.
The percentage still matches what I reported in the initial report. And it is still one of the slowest checks.
PiotrZSL commentedon Jan 24, 2024
Lot of code, lot of using directives. This check need to be re-written to use RecursiveASTMatcher like bugprone-reserved-identifier were. misc-unused-using-decls would also benefit from ignoring system headers, and there were WIP change for that, but it stuck as amount of reviewers is ... small.
As for bugprone-standalone-empty, that just need some tuning like TK_IgnoreUnlessSpelledInSource.
From "priority" point of view there are other changes like https://reviews.llvm.org/D150126 that would bring bigger improvements over all checks, not only this one. And other issues. When your points are valid, I just don't think that anyone will spend time on this in near time, unless issue can be reproduced on some bigger files where this check would take more than ~20s, otherwise that's just a noise caused by simply cost of an AST processing.
firewave commentedon Jan 18, 2025
Possibly improved by #123454.
vbvictor commentedon Aug 25, 2026
Please re-evaluate result with newer version. Feel free to reopen issue