4 ms·

> be, before C and C++ took over the zeitgeist of compilation times. I wouldn’t put them together. C compilation is not the fastest but fast enough to not be a

> be, before C and C++ took over the zeitgeist of compilation times. I wouldn’t put them together. C compilation is not the fastest but fast enough to not be a big problem. C++ is a completely different story: not only it orders of magnitude slower (10x slower probably not the limit) on some codebases compiler needs a few Gb RAM (so you have to set -j below the number of CPU cores to avoid OOM).

pjmlp 1y ago
Back in 1999 - 2003, when I was working on a product mixing Tcl and C, the builds took one hour per platform, across Aix, Solaris, HP-UX, Red-Hat Linux, Windows 2000/NT build servers. C++ builds can be very slow versus plain old C, yes, assuming people do all mistakes there can be done. Like overuse of templates, not using binary libraries across modules, not using binary caches for object files (ClearMake style already available back in 2000), not using incremental compilation and incremental linking. To this day, my toy GTK+ Gtkmm application that I used for a The C/C++ Users Journal article, and have ported to Rust, compiles faster in C++ than Rust in a clean build, exactly because I don't need to start from the world genesis for all dependencies.
- adastra22 1y ago
  That’s not really an apples to apples comparison, is it?
  - pjmlp 1y ago
    I dunno why, the missing apple on Rust side is not embracing binary libraries like C and C++ do. Granted there are ways around it for similar capabilities, however they aren't the default, and defaults matter.
    - john01dav 1y ago
      You only build the world occasionally, like when cloning or staring a new project, or when upgrading your rustc version. It isn't your development loop. I do think that dynamic libraries are needed for better plugin support, though.
      - epage 1y ago
        > You only build the world occasionally Unless a shared dependency gets updated, RUSTFLAGS changes, a different feature gets activated in a shared dependency, etc. If Cargo had something like binary packages, it means they would be opaque to the rest of your project, making them less sensitive to change. Its also hard to share builds between projects because of the sensitivity to differences.
        adastra22 1y ago
        Except for RUSTFLAGS changes (which aren’t triggered by external changes), those only update the affected dependencies.
    - epage 1y ago
      I talked a bit about this at the Rust All Hands back in May. A lot of Rust packages that people ust are setup more like header-only libraries. We're starting to see more large libraries that better fit the model of binary libraries, like Bevy and Gitoxide. I'm laying down a vague direction for something more binary-library like (calling them opaque dependencies) as part of the `build-std` effort (allow custom builds of the standard library) as that is special cased as a binary library today.
- Bolwin 1y ago
  One hour? How did you develop anything?
  - jitl 1y ago
    That’s probably why tcl is in there, you use uncompiled scripting to orchestrate the native code, which is the part that takes hours to compile.
  - pjmlp 1y ago
    That was a clean build for the binary code used in Tcl scripts, every time someone would sync their local development with latests, or switch code branches. Plenty of code was Tcl scritping, and when re-compiling C code, only the affected set of files would be re-compiled, everything else was kept around in object files and binary libraries, and if not affected only required re-linking.
john01dav 1y ago
I have seen projects where ninja instead of make (both generated by cmake) is able to cleverly invoke the compiler such that CPU is saturated and ram isn't exhausted, and make couldn't (it reached oom).

pjmlp 1y ago

Back in 1999 - 2003, when I was working on a product mixing Tcl and C, the builds took one hour per platform, across Aix, Solaris, HP-UX, Red-Hat Linux, Windows 2000/NT build servers. C++ builds can be very slow versus plain old C, yes, assuming people do all mistakes there can be done. Like overuse of templates, not using binary libraries across modules, not using binary caches for object files (ClearMake style already available back in 2000), not using incremental compilation and incremental linking. To this day, my toy GTK+ Gtkmm application that I used for a The C/C++ Users Journal article, and have ported to Rust, compiles faster in C++ than Rust in a clean build, exactly because I don't need to start from the world genesis for all dependencies.

adastra22 1y ago
That’s not really an apples to apples comparison, is it?
- pjmlp 1y ago
  I dunno why, the missing apple on Rust side is not embracing binary libraries like C and C++ do. Granted there are ways around it for similar capabilities, however they aren't the default, and defaults matter.
  - john01dav 1y ago
    You only build the world occasionally, like when cloning or staring a new project, or when upgrading your rustc version. It isn't your development loop. I do think that dynamic libraries are needed for better plugin support, though.
    - epage 1y ago
      > You only build the world occasionally Unless a shared dependency gets updated, RUSTFLAGS changes, a different feature gets activated in a shared dependency, etc. If Cargo had something like binary packages, it means they would be opaque to the rest of your project, making them less sensitive to change. Its also hard to share builds between projects because of the sensitivity to differences.
      - adastra22 1y ago
        Except for RUSTFLAGS changes (which aren’t triggered by external changes), those only update the affected dependencies.
  - epage 1y ago
    I talked a bit about this at the Rust All Hands back in May. A lot of Rust packages that people ust are setup more like header-only libraries. We're starting to see more large libraries that better fit the model of binary libraries, like Bevy and Gitoxide. I'm laying down a vague direction for something more binary-library like (calling them opaque dependencies) as part of the `build-std` effort (allow custom builds of the standard library) as that is special cased as a binary library today.
Bolwin 1y ago
One hour? How did you develop anything?
- jitl 1y ago
  That’s probably why tcl is in there, you use uncompiled scripting to orchestrate the native code, which is the part that takes hours to compile.
- pjmlp 1y ago
  That was a clean build for the binary code used in Tcl scripts, every time someone would sync their local development with latests, or switch code branches. Plenty of code was Tcl scritping, and when re-compiling C code, only the affected set of files would be re-compiled, everything else was kept around in object files and binary libraries, and if not affected only required re-linking.

john01dav 1y ago

I have seen projects where ninja instead of make (both generated by cmake) is able to cleverly invoke the compiler such that CPU is saturated and ram isn't exhausted, and make couldn't (it reached oom).