There's a good discussion on minimizing heap allocations: https://nnethercote.github.io/perf-book/heap-allocations.htm...
UPDATE: I should probably add that just about everything that is a move could turn into a copy, and Rust uses the move paradigm so often that is is easy to not even see what might turn into a copy. For small vars, it is no big deal, but for huge stack arrays it could add up. For example, if you init your buffer in a block and then return it as a binding, it will often be copied which can be painful.
let my_buffer = {
let buffer: [u8; 1_000_000] = [0; 1_000_000];
// Do stuff to init buffer here
buffer // This might end up mem copying the buffer out of the block
};
(everything I said could be wrong, I'm not a compiler guy, I just didn't feel like qualifying every single statement)
No, the risk of stack overflow would be the typical reason
> Stacks unwind, so you can't pass around pointers to it
Sure you can, you just can't _return_ a reference to something on the stack, but within the data's lifetime you can pass refs to it to other functions
> And the stack is fast because it's often mostly in CPU cache, but that won't be true if you have 100 megs sitting there
The stack is also fast because allocation is free (pointer bump) vs. calling a free list allocator (aka malloc). Cache hits for a large buffer would likely be about the same. If the buffer were small, I would agree on the likelihood of it being in CPU cache.
> This is what the heap is for, it has nothing to do with Rust itself.
In many scenarios moves can and are optimized away, so yes, this has something to do with Rust. I will admit my use case was very contrived and is not a typical use case, but it was very valid (even if not typical).
For this particular example it seems that the rust compiler is failing to implement the equivalent of NRVO though, so it is not necessarily related to mives. Do rust semantics allow NRVO? There are no copy/move constructors with side effects, so the only issue is object identity.
Disclaimer: I'm just a c++ programmer, I know very little about rust.
using array = std::array<int, 10>;
array make(array* y) {
array result = {...};
assert(&result != y);
return result;
}
array x = make(&x);
As you hint at, guard probes without stack probes don't provide guaranteed segfaults -- sparse access to stack allocations can skip the guard and smash another stack (or whatever) easily enough. And stack probes for large sparse allocations firmly make stack allocations more expensive than heap allocations (since pages must be allocated for the whole allocation, even if it's unused), which is a pretty huge downside.