4 ms·

All my rust projects (>1 million LOC at this point) compile 10x faster than our C++ code base ever did (300k LOC and shrinking, used to be 900k LOC c++ but over

All my rust projects (>1 million LOC at this point) compile 10x faster than our C++ code base ever did (300k LOC and shrinking, used to be 900k LOC c++ but over the last 4 years all new functionality has been rust, and every substantial fix of existing functionality has resulted in rewriting C++ code to Rust). How to do this is surprisingly easy: write small crates that do 1 thing. A Rust crate is a C++ TU, pretty much everybody that complains that Rust is slow is comparing Rust crates that are 10-100x larger than the size of the .cpp files they use in their C++ projects. For some reason, people, and particularly C++ devs, like to write huge Rust crates (I’ve seen crates with 200k LOC). They’d never write a 200k LOC .cpp file, so I really don’t get why they do this. Either way, if your Rust compile times are slow, it’s probably your and only your fault. How to get blazing fast Rust compile times isn’t a secret. We have a lot of data of the time it took to compile C++ TUs vs the equivalent Rust crate, and Rust reliably compiles at least one order of magnitude faster, sometimes two. All our crates are less than 10kLOC, median is 1812 LOC. Rust crate binary compatibility is also pretty awesome, so that in general a new hire does not need to compile anything at all (an unmodified build just fetches binary objects from sccache). When they start modifying the project, only those binary objects that actually changed have to be recompiled, the rest is just dynamically linked. This gives you <5s edit-compile cycle if you are working on a leaf crate.

pjmlp 5y ago
Now go around and apply the same build optimizations to the C++ source base, including the use of incremental compilation, incremental linking, pre-compiled headers, export templates in TU, making use of lib files. If your C++ compile times are slow, it’s probably your and only your fault.
- volta83 5y ago
  Our C++ code base has been using Clang modules and all those optimizations (explicit template instantiations, incremental linking, dynamic libraries, etc.) since 2011.. It also supports unity builds, and C++ modules TS, so we can compare the performance of all 3 approaches Rust consistently beats all of them by at least an order of magnitude in apples to apples comparisons, with at least an order of magnitude less fiddling in terms of modifying the source code, fiddling with build system and compiler options, etc. So in our experience, Rust gives you 10x faster compile times with 10x less effort than C++ if you use similarly sized compilation units. Rust makes it easy to write compilation units that are 10x-100x faster than C++ ones and still compile reasonably fast for their size, but we don’t allow this by convention (we have a clippy lint that rejects crates that are too large).
  - pjmlp 5y ago
    Which happens to be known to not be as good as MSVC in incremental linking and pre-compiled headers. So do you also have something comparable to Incredibuild and Clearcase derived object files in place?
    - volta83 5y ago
      Pre Compiled Headers are 1:1 perf wise identical to Clang modules for our 1 million Loc C++ project modulo system noise. There was no difference in compilation speed, neither for clean nor incremental builds. We supported them for a while (until 2015 or so; no perf difference over 3 years), but Clang modules gave the exact same perf and was easier to use, and unity builds were much faster for clean builds anyways, so there was no point in maintaining PCH in parallel to these two other options. For people that are not aware, PCH, modules, etc. bought us 20-40% compile time reduction. I expect 30% or so to be typical for projects that are using TUs correctly. A 30% compile time reduction or even a 2x compile time reduction is not “life changing”. It’s peanuts. Particularly compared with the 10-100x compile time reductions that Rust gives you. From 100min to 1 min, that’s a huge difference. From 100 min to 50-70min? That’s an irrelevant difference.

pjmlp 5y ago

Now go around and apply the same build optimizations to the C++ source base, including the use of incremental compilation, incremental linking, pre-compiled headers, export templates in TU, making use of lib files. If your C++ compile times are slow, it’s probably your and only your fault.

volta83 5y ago
Our C++ code base has been using Clang modules and all those optimizations (explicit template instantiations, incremental linking, dynamic libraries, etc.) since 2011.. It also supports unity builds, and C++ modules TS, so we can compare the performance of all 3 approaches Rust consistently beats all of them by at least an order of magnitude in apples to apples comparisons, with at least an order of magnitude less fiddling in terms of modifying the source code, fiddling with build system and compiler options, etc. So in our experience, Rust gives you 10x faster compile times with 10x less effort than C++ if you use similarly sized compilation units. Rust makes it easy to write compilation units that are 10x-100x faster than C++ ones and still compile reasonably fast for their size, but we don’t allow this by convention (we have a clippy lint that rejects crates that are too large).
- pjmlp 5y ago
  Which happens to be known to not be as good as MSVC in incremental linking and pre-compiled headers. So do you also have something comparable to Incredibuild and Clearcase derived object files in place?
  - volta83 5y ago
    Pre Compiled Headers are 1:1 perf wise identical to Clang modules for our 1 million Loc C++ project modulo system noise. There was no difference in compilation speed, neither for clean nor incremental builds. We supported them for a while (until 2015 or so; no perf difference over 3 years), but Clang modules gave the exact same perf and was easier to use, and unity builds were much faster for clean builds anyways, so there was no point in maintaining PCH in parallel to these two other options. For people that are not aware, PCH, modules, etc. bought us 20-40% compile time reduction. I expect 30% or so to be typical for projects that are using TUs correctly. A 30% compile time reduction or even a 2x compile time reduction is not “life changing”. It’s peanuts. Particularly compared with the 10-100x compile time reductions that Rust gives you. From 100min to 1 min, that’s a huge difference. From 100 min to 50-70min? That’s an irrelevant difference.