jansvoboda11 added a comment. I tried optimizing this patch a bit. Instead of creating compact data structure and using binary search to find the preceding non-affecting file, I now store the adjustment information for each `FileID` in a vector. During deserialization, `FileID` is simply used as an index into `SLocEntryInfos`. That didn't yield any measurable improvement in performance, though. I think the regression must be coming from the `SourceLocation`/`Offset` to `FileID` translation.
I don't see any obvious way to work around that. `SourceManager::getFileIDLocal()` already implements some optimizations that makes accessing nearby offsets fast. A separate `SourceManager` would avoid this bottleneck, but I'm not sure how much work that would entail (seems substantial). @Bigcheese LMK if you're fine with the performance implications here. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136624/new/ https://reviews.llvm.org/D136624 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
