CodeGenModule::DeferredDecls std::map operator[] seem to be hot especially while code generating huge compilation units.
In such cases using DenseMap instead gives observable compile time improvement. Patch was tested on Linux build with default config acting as benchmark.
Build was performed on isolated CPU cores in silent x86-64 Linux environment following: https://llvm.org/docs/Benchmarking.html#linux rules.
Compile time statistics diff produced by perf and time before and after change are following:
instructions -0.15%, cycles -0.7%, max-rss +0.65%.
Using StringMap instead DenseMap doesn't bring any visible gains.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
https://llvm-compile-time-tracker.com/compare.php?from=c39d22d1968cf07e54b5816ba76dccef8acaace1&to=1958f5a5fb5be3fb5b6bad5079a2f3485db0b0e9&stat=instructions
mostly neutral but a tiny bit of green
seems fine to me
Comment Actions
This looks fine to change, and seems like a slight compile timeimprovement.
It seems that the only thing we use this for is .find, .erase, and operator[], all of which don't depend on iterator order, so this should not cause any problems with determinism.
Comment Actions
The change looks fine to me. I've started a set of benchmark to make sure it provides the expected speedup.