Thread

1. scoopr · 1791134211 · focus · HN ↗

   Huh, I kinda thought something like this was already being done, but perhaps it was a bit later stage. Neat!

   A kind of related shower thought I had, could rustc not instantiate generic methods, but write out what it expects to find (std::Vec<String>::push), and a separate build process listens to these, but makes sure already built ones are not built multiple times from the whole build.

   I don’t actually know how much of duplication there usually is, but I had gotten the impression that it would be part of the problem.

   Of course I’m no compiler engineer, and I’m sure there are complications like per crate build profiles, etc.

   1. kibwen · 1791138168 · focus · HN ↗

      > I kinda thought something like this was already being done

      It is. When building a crate, Cargo doesn't need to wait for all of that crate's dependencies to be completely finished compiling, instead it only needs to wait for each dependency to produce its metadata. The prototype here builds upon that existing machinery by causing metadata to be written earlier than it would otherwise be, prior to complete typechecking. It has the potential to increase the level of effective parallelism, so whether or not this has a benefit for a particular crate graph will depend on whether or not all of your cores are already effectively occupied during compilation or whether Cargo is letting cores lie idle while waiting on metadata to be produced.

      1. knuckleheads · 1791138642 · focus · HN ↗

         Yes, if you mostly have no extra cores already or if you have very wide unrelated deps, this mostly does nothing. Typically, this is not the case though so there is some good perf gains.

Unofficial Hacker News client; not affiliated with Y Combinator.