2 ms·
> The call to operator new can be optimized out (even if custom allocator is used) if > The lifetime of the coroutine state is strictly nested within the lifet
by tick_tock_tick 6y ago
> The call to operator new can be optimized out (even if custom allocator is used) if
> The lifetime of the coroutine state is strictly nested within the lifetime of the caller, and
the size of coroutine frame is known at the call site
in that case, coroutine state is embedded in the caller's stack frame (if the caller is an ordinary function) or coroutine state (if the caller is a coroutine)
Basically if you limit yourself to only functionality supported in Rust you'll never actually generate an allocation. Once you start using features Rust doesn't support you need to provided memory via some means.
https://en.cppreference.com/w/cpp/language/coroutines#Heap_allocation https://en.cppreference.com/w/cpp/language/coroutines#Heap_a...
- deleted 6y ago[deleted]
- millimeterman 6y agoWe'll have to wait and see how finished coroutines implementations perform, but I'm leery of the fact that sidestepping heap allocation relies on compiler optimizations. Optimizers can be fickle and in a language like C++/Rust, I like being 100% sure that the abstractions are zero-overhead.
- kccqzy 6y agoRelying on compiler optimizations is not the answer. When they work, you don't notice, but an unrelated change could very well change the compiler's state and optimization decisions, falling off a performance cliff. This is especially pronounced in languages that rely a lot on compiler optimizations. In Haskell you can purposefully use the singly linked list for very large collections, knowing they will be optimized out, until one day the compiler decided not to optimize that and now you have a problem. There's a reason C++17 made return-value-optimization a proper part of the language with mandatory elision of copies. People like guarantees. Optimizations are but the icing on the cake.