4 ms·

>Hmm. For me, fast compile times have vastly more ergonomic benefit than NLL. Well we weren't getting those anyway :(

foldr 8y ago
Yeah, I'm sure that this specific performance regression will have a minimal impact on overall compile times. But slow compilation is often a case of the death of 1000 cuts. Small performance regressions are tolerated over a long period, and eventually add up.
- steveklabnik 8y ago
  Compiler performance is always at the front of everyone’s mind, and we’re doing a lot of work to improve it. It’s not an easy problem. Both smaller, “shave off 1%” and larger “re-think the algorithms and data structures” approaches are being taken, but that takes time and effort. We’ll get there. Both compile times and NLL are, and have been, at the top of requests from production and hobbyist users alike for a long time now.
  - foldr 8y ago
    Sure, but in the end, if you allow new features to regress compile times, and you keep adding new features, then compile times are probably going to increase in the long run. (The logic here being that there are always more people interested in implementing new features than there are people interested in improving compile times.) However, some of the other comments suggest that NLL is actually a bug fix. If so, then obviously a performance regression is better than a buggy borrow checker.
    - steveklabnik 8y ago
      We track compile times on a per-commit basis. We don’t allow major regressions. But engineering is all about making hard calls. And, as the post mentions, while this may be a small regression in this particular step of the compiler, in an Amdahl’s Law sense, the speed of this step is not that big of a proportion of overall compile times. Most users won’t feel this difference. They do feel the pain of lexical lifetimes quite a bit, though. Which makes it a good trade off, even without regard for the soundness fixes.
      - foldr 8y ago
        I'm just putting a data point out there. Me = Rust user who'd rather have slightly faster compile times. But it's moot anyway given that this is a bug fix.
        steveklabnik 8y ago
        Yes, you are one of many. Everyone wants faster compiles.
        nicoburns 8y ago
        I'm also in the "really need faster compile times" camp. You may be interested in this thread on rust internals https://internals.rust-lang.org/t/next-steps-for-reducing-overall-compilation-time/8429/11 https://internals.rust-lang.org/t/next-steps-for-reducing-ov...
    - kibwen 8y ago
      For reference, there's a tag on the issue tracker for things that have been blocked on NLL to fix: https://github.com/rust-lang/rust/labels/NLL-fixed-by-NLL https://github.com/rust-lang/rust/labels/NLL-fixed-by-NLL Look for the ones that are also tagged "unsound" for the most serious instances.
- pjmlp 8y ago
  Until cargo gets proper support for binary libraries, and stops re-compiling common crates, things won't get better. Although I still hope they will eventually come around to fix it.
  - steveklabnik 8y ago
    That only affects the first compile, and while that is often one of the longest compiles, isn’t usually the pain point for most people.
    - pjmlp 8y ago
      When I need to wait 15m to compile my toy Gtk-rs project vs 5m for the former Gtkmm version, it already puts away the idea of trying anything more complex. And since competition is a good thing, Kotlin/Native with Gradle/Maven does allow for binary dependencies, with Swift 5.0 hopefully having them stabilized as well.
  - epage 8y ago
    Personally, I think I prefer the idea of adopting sccache more with some kind of trust system for sharing caches (official build servers, a consensus system, or something else?). After programming C++ for years, I much prefer relying on a lowest common denominator like C for a stable ABI. This also lets Rust do whatever optimizations it wants (like compacting enums / structs).
  - saghm 8y ago
    I've been using sccache (https://github.com/mozilla/sccache https://github.com/mozilla/sccache) lately, and it mostly solves this problem for me (although I agree with what others have mentioned that the issue isn't that much of a deal-breaker for me given how infrequently I run `cargo clean`.
    - wtetzner 8y ago
      You can also run cargo clean -p <project-name> to only clean the current project, and leave the dependencies.

Yeah, I'm sure that this specific performance regression will have a minimal impact on overall compile times. But slow compilation is often a case of the death of 1000 cuts. Small performance regressions are tolerated over a long period, and eventually add up.

steveklabnik 8y ago
Compiler performance is always at the front of everyone’s mind, and we’re doing a lot of work to improve it. It’s not an easy problem. Both smaller, “shave off 1%” and larger “re-think the algorithms and data structures” approaches are being taken, but that takes time and effort. We’ll get there. Both compile times and NLL are, and have been, at the top of requests from production and hobbyist users alike for a long time now.
- foldr 8y ago
  Sure, but in the end, if you allow new features to regress compile times, and you keep adding new features, then compile times are probably going to increase in the long run. (The logic here being that there are always more people interested in implementing new features than there are people interested in improving compile times.) However, some of the other comments suggest that NLL is actually a bug fix. If so, then obviously a performance regression is better than a buggy borrow checker.
  - steveklabnik 8y ago
    We track compile times on a per-commit basis. We don’t allow major regressions. But engineering is all about making hard calls. And, as the post mentions, while this may be a small regression in this particular step of the compiler, in an Amdahl’s Law sense, the speed of this step is not that big of a proportion of overall compile times. Most users won’t feel this difference. They do feel the pain of lexical lifetimes quite a bit, though. Which makes it a good trade off, even without regard for the soundness fixes.
    - foldr 8y ago
      I'm just putting a data point out there. Me = Rust user who'd rather have slightly faster compile times. But it's moot anyway given that this is a bug fix.
      - steveklabnik 8y ago
        Yes, you are one of many. Everyone wants faster compiles.
      - nicoburns 8y ago
        I'm also in the "really need faster compile times" camp. You may be interested in this thread on rust internals https://internals.rust-lang.org/t/next-steps-for-reducing-overall-compilation-time/8429/11 https://internals.rust-lang.org/t/next-steps-for-reducing-ov...
  - kibwen 8y ago
    For reference, there's a tag on the issue tracker for things that have been blocked on NLL to fix: https://github.com/rust-lang/rust/labels/NLL-fixed-by-NLL https://github.com/rust-lang/rust/labels/NLL-fixed-by-NLL Look for the ones that are also tagged "unsound" for the most serious instances.
pjmlp 8y ago
Until cargo gets proper support for binary libraries, and stops re-compiling common crates, things won't get better. Although I still hope they will eventually come around to fix it.
- steveklabnik 8y ago
  That only affects the first compile, and while that is often one of the longest compiles, isn’t usually the pain point for most people.
  - pjmlp 8y ago
    When I need to wait 15m to compile my toy Gtk-rs project vs 5m for the former Gtkmm version, it already puts away the idea of trying anything more complex. And since competition is a good thing, Kotlin/Native with Gradle/Maven does allow for binary dependencies, with Swift 5.0 hopefully having them stabilized as well.
- epage 8y ago
  Personally, I think I prefer the idea of adopting sccache more with some kind of trust system for sharing caches (official build servers, a consensus system, or something else?). After programming C++ for years, I much prefer relying on a lowest common denominator like C for a stable ABI. This also lets Rust do whatever optimizations it wants (like compacting enums / structs).
- saghm 8y ago
  I've been using sccache (https://github.com/mozilla/sccache https://github.com/mozilla/sccache) lately, and it mostly solves this problem for me (although I agree with what others have mentioned that the issue isn't that much of a deal-breaker for me given how infrequently I run `cargo clean`.
  - wtetzner 8y ago
    You can also run cargo clean -p <project-name> to only clean the current project, and leave the dependencies.