4 ms·

Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints.

Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.

xena 5y ago
Doesn't the compiler optimize out clones when it can?
- sanxiyn 5y ago
  No, not really.
- tylerhou 5y ago
  Probably not; detecting unnecessary clones is expensive for non-trivial cases. If a human can't prove that the clone isn't necessary (by writing the code in such a manner that the borrow checker accepts), I doubt the compiler could.
- toby 5y ago
  There's a Cargo tool called "clippy" which will tell you if it finds unnecessary clones.
rogers18445 5y ago
The vast majority of the code you write is glue code, you can be as inefficient when writing it as you want and it doesn't matter. Optimize only what the profiler tells you your cpu is spending real time in.
brundolf 5y ago
This is one of the psychological traps I've experienced writing Rust: in Python or Java you can't hope to make things more efficient at a certain point. You couldn't get clever with string re-use if you tried, etc. So you're content to just move forward and be practical. Whereas in Rust you know that it's probably possible to use a &str there instead of a String. If you just bang on it a little longer, you can make it just a bit more optimal. The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. You usually don't have to optimize them out! Your code will probably be faster than Java even with a bunch of clones, etc! But there's this temptation that's really hard for programmers to resist, to sink hours and hours into making things just slightly more optimal given the opportunity. You have to consciously talk yourself out of that if you want to be productive.
- masklinn 5y ago
  > The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. That's… not exactly true. `Vec::new` is completely free so that's a different debate, but much as in C++ or C allocations in Rust are much more expensive than in managed languages: 1. system allocators genuinely suck, all of them, though some more than others (iirc macos' is especially bad) 2. managed languages can much more easily specialised allocation strategies (freelists, bump allocators, type-custom allocation strategies), this is either difficult / impossible (no custom allocators) or way more painful (manually pass custom allocators in) in Rust As a result, allocations in Rust are really tremendously slow by default, it's not too rare to see questions about Rust programs which are slower than managed equivalents, in release mode. Because the rust program is allocation heavy (relatively), it might have 10% the allocations of the non-rust program but the allocations are 100 times more expensive.
  - brundolf 5y ago
    Interesting, I hadn't heard this before. Do you have any resources I could read? Edit: I do know that languages where strings are immutable use that fact to do lots of optimization (automatically sharing "copied" strings and just cloning reference-counters, for example), but you can accomplish some of this in Rust too with Rc<> or even persistent data structures if you really want to. And of course there are cases where it's more efficient to actually mutate a string, which these languages can't do. But it sounds like you're talking about something else?
    - estebank 5y ago
      There are three strategies that other languages use automatically that you can also apply in Rust by hand: string interning, small string optimization and "Copy-on-write". For the first and second, you can use some existing crate like https://docs.rs/string-interner/0.12.2/string_interner/ https://docs.rs/string-interner/0.12.2/string_interner/ and https://github.com/rust-analyzer/smol_str https://github.com/rust-analyzer/smol_str. For the later, you can use Cow<'_, str> https://doc.rust-lang.org/std/borrow/enum.Cow.html https://doc.rust-lang.org/std/borrow/enum.Cow.html. I'm having trouble thinking of a case where Rc<String> would be appropriate.

Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.

xena 5y ago

Doesn't the compiler optimize out clones when it can?

sanxiyn 5y ago
No, not really.
tylerhou 5y ago
Probably not; detecting unnecessary clones is expensive for non-trivial cases. If a human can't prove that the clone isn't necessary (by writing the code in such a manner that the borrow checker accepts), I doubt the compiler could.
toby 5y ago
There's a Cargo tool called "clippy" which will tell you if it finds unnecessary clones.

rogers18445 5y ago

The vast majority of the code you write is glue code, you can be as inefficient when writing it as you want and it doesn't matter. Optimize only what the profiler tells you your cpu is spending real time in.

brundolf 5y ago

This is one of the psychological traps I've experienced writing Rust: in Python or Java you can't hope to make things more efficient at a certain point. You couldn't get clever with string re-use if you tried, etc. So you're content to just move forward and be practical. Whereas in Rust you know that it's probably possible to use a &str there instead of a String. If you just bang on it a little longer, you can make it just a bit more optimal. The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. You usually don't have to optimize them out! Your code will probably be faster than Java even with a bunch of clones, etc! But there's this temptation that's really hard for programmers to resist, to sink hours and hours into making things just slightly more optimal given the opportunity. You have to consciously talk yourself out of that if you want to be productive.

masklinn 5y ago
> The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter. That's… not exactly true. `Vec::new` is completely free so that's a different debate, but much as in C++ or C allocations in Rust are much more expensive than in managed languages: 1. system allocators genuinely suck, all of them, though some more than others (iirc macos' is especially bad) 2. managed languages can much more easily specialised allocation strategies (freelists, bump allocators, type-custom allocation strategies), this is either difficult / impossible (no custom allocators) or way more painful (manually pass custom allocators in) in Rust As a result, allocations in Rust are really tremendously slow by default, it's not too rare to see questions about Rust programs which are slower than managed equivalents, in release mode. Because the rust program is allocation heavy (relatively), it might have 10% the allocations of the non-rust program but the allocations are 100 times more expensive.
- brundolf 5y ago
  Interesting, I hadn't heard this before. Do you have any resources I could read? Edit: I do know that languages where strings are immutable use that fact to do lots of optimization (automatically sharing "copied" strings and just cloning reference-counters, for example), but you can accomplish some of this in Rust too with Rc<> or even persistent data structures if you really want to. And of course there are cases where it's more efficient to actually mutate a string, which these languages can't do. But it sounds like you're talking about something else?
  - estebank 5y ago
    There are three strategies that other languages use automatically that you can also apply in Rust by hand: string interning, small string optimization and "Copy-on-write". For the first and second, you can use some existing crate like https://docs.rs/string-interner/0.12.2/string_interner/ https://docs.rs/string-interner/0.12.2/string_interner/ and https://github.com/rust-analyzer/smol_str https://github.com/rust-analyzer/smol_str. For the later, you can use Cow<'_, str> https://doc.rust-lang.org/std/borrow/enum.Cow.html https://doc.rust-lang.org/std/borrow/enum.Cow.html. I'm having trouble thinking of a case where Rc<String> would be appropriate.