Instantiating the array via default seems to have a very large stack footprint

[prestwich]

May be misunderstanding something here, but it looks like the instantiation process has an unnecessarily heavy stack footprint. I expect to have a few MB of stack space available, but can't instantiate an array of size larger than ~200kB.

#[cfg(test)]
mod test {
    #[test]
    fn it_defaults() {
        // 208896
        dbg!(std::mem::size_of::<GenericArray<[u64; 32], U816>>());
        // 209152
        dbg!(std::mem::size_of::<GenericArray<[u64; 32], U817>>());
        
        // Works
        GenericArray::<[u64; 32], U816>::default();
        
        // Stack Overflow
        GenericArray::<[u64; 32], U817>::default();
    }
}

[novacrazy]

Interesting. Anything over U806 overflows the stack on my machine. I'll look into this more.

[prestwich]

Some additional info from playing around with this: Using generic_array::transmute to turn large arrays into large GenericArrays will stack overflow, while using std::mem::transmute will work

[novacrazy]

Yes, generic_array::transmute requires copying the data, but it's not used here.

The problem is mostly due to Rust/LLVM in the unoptimized debug mode simply not performing ANY return-value optimization, resulting in many duplicate copies on the stack as it is passed around. There isn't much I can do about that, other than providing an API to initialize a generic-array within an already existing chunk of memory, but that's rather obtuse.

Perhaps there is an issue for Rust itself regarding return-value optimizations, but for now all I can do is recommend you compile with opt-level=1 or 2 for your dev profile.

[prestwich]

sounds good, thanks!

[sollyucko]

RFC about Return Value Optimization / Placement by Return: rust-lang/rfcs#2884

[novacrazy]

It's been a while, but I've made some headway in improving this situation on the latest master branch. See #160 for more info, but in at least that test case I was able to remove almost all excess stack allocations and memcpys by cleverly avoiding "moving" the array into/out of new types.

Of course, this is only an issue in Debug, and release builds still compile to essentially the same code.