4 ms·

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and i

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc<Box<..>>.

PartiallyTyped 3y ago
Compiling clippy certainty doesn’t take that long and it’s a substantially larger project. What you describe is pretty weird to be honest.
Fiahil 3y ago
> after the number of times I resorted to things like Arc<Box<..>>. ... What are you doing ? It's definitively unusual.
- dvt 3y ago
  > ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc<Box<...>>` or `Arc<Mutex<Box<...>>>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely clear, knowing exactly what parts of every struct is shareable (Arc) & mutable (Mutex). [1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
  - Fiahil 3y ago
    > No it's not, it's extremely common. Arc-Mutex yes, Arc-Box no. It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html https://doc.rust-lang.org/std/sync/struct.Arc.html > The type Arc<T> provides shared ownership of a value of type T, allocated in the heap. Moreover, you don't even need the box for a dyn : https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3c76d2d https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3...
    - dvt 3y ago
      > Arc-Mutex yes, Arc-Box no. Yeah, looks like Arc-Box is kind of pointless, but isn't there some thread locality reason why people wrap `Box` in `Arc`? I remember reading something about it a while ago but maybe I'm misremembering.
      - MaulingMonkey 3y ago
        To play devil's advocate: `Arc<T>` places the refcounts immediately before `T` in memory. If you are desperate to have `T` and `T`'s refcounts be on different cachelines to reduce false sharing in some contrived scenario, `Arc<Box<T>>` would technically accomplish this. I think a more realistic optimization would be to pad the start of `T` however. `Box<Box<T>>` and `Arc<Box<T>>` are thin pointers (size ≈ size_of::<usize>()) even when `Box<T>` is a fat pointer (size ≈ 2*size_of::<usize>() because `T` is `str`, `[u8]`, `dyn SomeTrait`, etc.). While various "thin" crates are typically saner alternatives for FFI or memory density (prefixing lengths/vtables in the pointed-at data instead of incurring double-indirection and double-allocation), these double boxes are a quick and dirty way of accomplishing guaranteed thin pointers with only `std` / `alloc`. I would not call either of these use cases "extremely common" however.
    - YetAnotherNick 3y ago
      I don't exactly remember the exact thing I used that's why I said "I resorted to things like.. ". Also, I used actix web, which could be the reason of slow compiling code.
  - flohofwoe 3y ago
    At that point a regular GC is probably faster (at least from my experience of doing memory management in C++ with ref-counted smart pointers, which has a 'death-by-a-thousand-cuts' performance profile, e.g. the refcounting overhead is smeared over the whole code base and doesn't show up as obvious hotspots in the profiler).
matesz 3y ago
I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies. [1] https://github.com/makepad/makepad/ https://github.com/makepad/makepad/
- flohofwoe 3y ago
  IMHO Makepad also has an exceptionally readable Rust code style, which is a very rare thing (maybe that simple Rust style even contributes to the good build times, dunno) - but also: from the pov of a C programmer, 200 kloc in 10..15 seconds is still quite bad ;)
  - timschmidt 3y ago
    How quickly can you verify the memory safety of that C program in addition to compiling it though? When comparing like to like, C no longer looks so fast.
    - gkbrk 3y ago
      Rust code with unsafe still compiles slowly. And safe subsets of C still compile quickly.
      - timschmidt 3y ago
        That is exactly the opposite of my experience.
- deleted 3y ago
  [deleted]
- YetAnotherNick 3y ago
  I used actix web, could it be the reason for slow compile?

PartiallyTyped 3y ago

Compiling clippy certainty doesn’t take that long and it’s a substantially larger project. What you describe is pretty weird to be honest.

Fiahil 3y ago

> after the number of times I resorted to things like Arc<Box<..>>. ... What are you doing ? It's definitively unusual.

dvt 3y ago
> ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc<Box<...>>` or `Arc<Mutex<Box<...>>>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely clear, knowing exactly what parts of every struct is shareable (Arc) & mutable (Mutex). [1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
- Fiahil 3y ago
  > No it's not, it's extremely common. Arc-Mutex yes, Arc-Box no. It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html https://doc.rust-lang.org/std/sync/struct.Arc.html > The type Arc<T> provides shared ownership of a value of type T, allocated in the heap. Moreover, you don't even need the box for a dyn : https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3c76d2d https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3...
  - dvt 3y ago
    > Arc-Mutex yes, Arc-Box no. Yeah, looks like Arc-Box is kind of pointless, but isn't there some thread locality reason why people wrap `Box` in `Arc`? I remember reading something about it a while ago but maybe I'm misremembering.
    - MaulingMonkey 3y ago
      To play devil's advocate: `Arc<T>` places the refcounts immediately before `T` in memory. If you are desperate to have `T` and `T`'s refcounts be on different cachelines to reduce false sharing in some contrived scenario, `Arc<Box<T>>` would technically accomplish this. I think a more realistic optimization would be to pad the start of `T` however. `Box<Box<T>>` and `Arc<Box<T>>` are thin pointers (size ≈ size_of::<usize>()) even when `Box<T>` is a fat pointer (size ≈ 2*size_of::<usize>() because `T` is `str`, `[u8]`, `dyn SomeTrait`, etc.). While various "thin" crates are typically saner alternatives for FFI or memory density (prefixing lengths/vtables in the pointed-at data instead of incurring double-indirection and double-allocation), these double boxes are a quick and dirty way of accomplishing guaranteed thin pointers with only `std` / `alloc`. I would not call either of these use cases "extremely common" however.
  - YetAnotherNick 3y ago
    I don't exactly remember the exact thing I used that's why I said "I resorted to things like.. ". Also, I used actix web, which could be the reason of slow compiling code.
- flohofwoe 3y ago
  At that point a regular GC is probably faster (at least from my experience of doing memory management in C++ with ref-counted smart pointers, which has a 'death-by-a-thousand-cuts' performance profile, e.g. the refcounting overhead is smeared over the whole code base and doesn't show up as obvious hotspots in the profiler).

matesz 3y ago

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies. [1] https://github.com/makepad/makepad/ https://github.com/makepad/makepad/

flohofwoe 3y ago
IMHO Makepad also has an exceptionally readable Rust code style, which is a very rare thing (maybe that simple Rust style even contributes to the good build times, dunno) - but also: from the pov of a C programmer, 200 kloc in 10..15 seconds is still quite bad ;)
- timschmidt 3y ago
  How quickly can you verify the memory safety of that C program in addition to compiling it though? When comparing like to like, C no longer looks so fast.
  - gkbrk 3y ago
    Rust code with unsafe still compiles slowly. And safe subsets of C still compile quickly.
    - timschmidt 3y ago
      That is exactly the opposite of my experience.
deleted 3y ago
[deleted]
YetAnotherNick 3y ago
I used actix web, could it be the reason for slow compile?