3 ms·

> plus 8 bytes for the tag The tag can often be stored inline in the data, so doesn't necessarily require extra space. > because they always take up as much s

• estebank 3y ago
  The alternative would be for Rust to generate machine code for the following enum Foo { Bar, Qux([i32; 1024]), } as if the user had written enum Foo { Bar, Qux(Box<[i32; 1024]>), } I don't think it's a good idea to do that kind of silent transformation, instead teach the developer about their options. That way the application's performance doesn't suddenly shift after changing a few parts of unrelated code that accidentally causes some threshold to be crossed that changes the performance characteristics of binary being produced. Today, clippy does what I think is the right thing: it teaches the user warning: large size difference between variants --> src/main.rs:1:1 | 1 | / enum Foo { 2 | | Bar, | | --- the second-largest variant carries no data at all 3 | | Qux([i32; 1024]), | | ---------------- the largest variant contains at least 4096 bytes 4 | | } | |_^ the entire enum is at least 4100 bytes | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant = note: `#[warn(clippy::large_enum_variant)]` on by default help: consider boxing the large fields to reduce the total size of the enum | 3 | Qux(Box<[i32; 1024]>), | ~~~~~~~~~~~~~~~~
  • chriskrycho 3y ago
    When you combine this with rust-analyzer's hints for the sizes of items, it makes it much easier to spot this kind of stuff and resolve it automatically while developing, too.