ArcsinX added a comment. In D83621#2146706 <https://reviews.llvm.org/D83621#2146706>, @sammccall wrote:
> Wow, yeah, this seems pretty bad! I'm not very familiar with this code. I'm > curious, for "it tooks more than 1 second" - what OS is this on? Windows. I faced this problem on a huge project and it takes 7 seconds for `MatchTrie.findEquivalent()` to return. > My guess is that way back when, the performance of looking up a CDB entry > that didn't exist wasn't a big deal, or windows support wasn't a big thing, > or this was just an oversight. > > I think it would be slightly cleaner to fix this in the trie itself, either: Firstly, I wanted to fix this problem in `FileMatchTrie`, but for caching solution we need to update cache at every `instert()` call, but for caching solution inside `JSONCompilationDatabase` we can avoid this, because all inserts already done at `JSONCompilationDatabase::parse()`. > - don't scan for equivalences if the set of candidates exceeds some size > threshold (10 or so) > - don't scan for equivalences if the node we'd scan under is the root After such fixes `JSONCompilationDatabase::getCompileCommands()` will return other results than before in some cases. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83621/new/ https://reviews.llvm.org/D83621 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
