You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that the obstacks implementation already minimizes allocations - particularly if you set an appropriately large initial capacity - I have to wonder how much of a performance benefit this would actually be?
I mean, if you have a working alloca(), it might be better to just use it directly. Also, unlike alloca(), an obstack can be passed to child functions that can in turn add things to the stack, and return references to values within it; I don't see how you could preserve that capability.
That said, what I could do is make the initial allocation on the stack, then switch to the heap when that allocation runs out. That'd probably give you very similar benefits to alloca() for many usecases while still preserving the ability to pass the stack to child functions. Specifically, I could do this by adding another constructor, Obstack::from_initial_slice(initial_slice: &mut [u8]), that the callee could then allocate themselves:
let mut stack_segment: [u8; 1024] = unsafe { std::mem::unitialized() };
let stack = Obstack::from_initial_slice(&stack_segment);
(or via something like ArrayVec to avoid unsafeness)
Would it be possible to use alloca() when available ? This would make allocations equivalent to just a pointer adjust.