Optimizing Rust Struct Size

Re:Optimizing Rust Struct Size by openasocket on Saturday April 15, 2017 @05:49PM (#14123029)

anyone know how this plays with generics? With it generate different, optimal layouts for each instantiation, i.e. will HashMap<u64,64> have a different layout than Hashmap<u16,u32>? Because that would be a huge win

[ Parent | on HN ]

Re:Optimizing Rust Struct Size by CAMLORN on Saturday April 15, 2017 @06:59PM (#14123315)

Yes, it will do exactly that.

[ Parent | on HN ]

Re:Optimizing Rust Struct Size by frankmcsherry on Sunday April 16, 2017 @01:34PM (#14126551)

I think in this case it doesn't, because the `HashMap` implementation just stores everything behind an untyped pointer.

https://github.com/rust-lang/rust/blob/master/src/libstd/col...

It would be cool to see if the "we'll manage our own pointers, thanks" approach makes less sense with this optimization in place. It would be nice; the source is pretty inscrutable, mostly in the interest of performance, I think.

Edit: Or, maybe more importantly: in the untyped memory they store hashes and (K,V) pairs separately, so I think the only opportunity is to swap (K,V) for (V,K).

[ Parent | on HN ]

Re:Optimizing Rust Struct Size by CAMLORN on Monday April 17, 2017 @12:36PM (#14132257)

I haven't looked at libstd, so I can't comment to that specifically. But we don't reorder two-field structs.

Rustc special cases them in a lot of places to do things that I will not even pretend to understand, and not reordering 2-element structs keeps them working. Since this already took 6 months of my free time (I have a lot of free time, though not 40 hours a week admittedly), this was for the best.

You can make an argument that we should have, but it doesn't matter from the user's perspective. (a, b) is the same size as (b, a) no matter what a and b are.

[ Parent | on HN ]

Re:Optimizing Rust Struct Size by pcwalton on Saturday April 15, 2017 @06:13PM (#14123135)

Yes, what you describe could happen.

[ Parent | on HN ]