5 ms·

I don't see that debunking it. Instead, it says "usually". That means that it depends on the project. There is definitely Rust code that takes exponential time

• steveklabnik 1y ago
  I say “usually” because of course sometimes bugs happen and of course you can conduct degenerate stress tests. But outside of those edge cases, it’s not an issue. If it were, blog posts that talk about lowering compile times would be discussing avoiding the borrow checker to get better times, but they never do. It’s always other things.
  • resurrectedcyb 1y ago
    Is there any tool for Rust that does profiling that detects what part of compilation time is caused by what? Like, a tool that reports: - Parsing: x ms - Type checking: y ms - LLVM IR generation: z ms And have there been any statistics done on that across open-source projects, like mean, median, percentiles and so on? I am asking because it should depend a lot on each project what is costly in compile time, making it more difficult to analyse. And I am also curious about how many projects are covered by "edge cases", if it is 1%, 0.1%, 0.01%, and so on.
    • steveklabnik 1y ago
      The post my original comment is on discusses doing this at length. > And have there been any statistics done on that across open-source projects, like mean, median, percentiles and so on? I am not aware of any. But in all the posts on this topic over the years, codegen always ends up being half the time. It’s why cargo check is built the way it is, and why it’s always faster than a full build. If non-codegen factors were significant with any regularity, you’d be seeing reports of check being super slow compared to build.
      • resurrectedcyb 1y ago
        I have actually seen a few posts here and there of 'cargo check' being slow. I have also heard of complaints of rust-analyzer being slow, though rust-analyzer may be doing more than just 'cargo check'. https://www.reddit.com/r/rust/comments/1daip72/rust_checkrunbuild_suddenly_extreme_slow_to_a/ https://www.reddit.com/r/rust/comments/1daip72/rust_checkrun... May not be indicative, not sure what crate the author was using.
        • steveklabnik 1y ago
          cargo check can be slow but what I mean is relative to a full build. Large projects are going to be slow to build by virtue of being large.
          • resurrectedcyb 1y ago
            That project had 'cargo check' take 15-20 minutes, though it might not have been indicative, the submitter posted an update about how it was fixed. This may be a better example. https://github.com/rust-lang/rust/issues/132064 https://github.com/rust-lang/rust/issues/132064 >cargo check with 1.82: 6m 19s >cargo check with 1.81: 1m 22s It may be difficult to fix. https://github.com/rust-lang/rust/issues/132064#issuecomment-2461802228 https://github.com/rust-lang/rust/issues/132064#issuecomment... >Triage notes (AFAIUI): #132625 is merged, but the compile time is not fully clawed back as #132625 is a compromise between (full) soundness and performance in favor of a full revert (full revert would bring back more soundness problems AFAICT) Update: They fixed it, but another issue surfaced, possibly related, as I read the comments.
    • 3836293648 1y ago
      Yes, there's a -Ztime-passes, but it's nightly only (or stable with the bootstrap env var set)
      • steveklabnik 1y ago
        My understanding is that -Ztime-passes isn't very accurate anymore, as it's not integrated into the query system well, or something.