4 ms·

I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.

by cschep 4y ago

maccard 4y ago
Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.
aliqot 4y ago
In my experience, yes.
sli 4y ago
There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...
meindnoch 4y ago
By a wide margin.
nequo 4y ago
Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293
bfrog 4y ago
Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
raphlinus 4y ago
As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
- maccard 4y ago
  > you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
  - raphlinus 4y ago
    Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
pjmlp 4y ago
It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.

I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.

by cschep 4y ago

I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.

Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.

aliqot 4y ago

In my experience, yes.

sli 4y ago

There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...

meindnoch 4y ago

By a wide margin.

nequo 4y ago

Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293

bfrog 4y ago

Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.

raphlinus 4y ago

As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.

maccard 4y ago
> you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
- raphlinus 4y ago
  Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.

pjmlp 4y ago

It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.