Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
prestwich opened this issue Jul 30, 2020 · 5 comments

Comments

@prestwich
Copy link

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
Copy link
Collaborator

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

@prestwich
Copy link
Author

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
Copy link
Collaborator

novacrazy commented Jul 31, 2020

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
Copy link
Author

sounds good, thanks!

@sollyucko
Copy link

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

@novacrazy novacrazy mentioned this issue Mar 29, 2023
Merged
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants