3 ms·
> No it's not. > What's happening is some of the run time overhead is being reduced. I believe wycats was responding specifically to > Rust uses 'drop flags
by dbaupp 12y ago
> No it's not.
> What's happening is some of the run time overhead is being reduced.
I believe wycats was responding specifically to
> Rust uses 'drop flags', which are extra bytes at the end of struct instances in memroy, to track objects and keep meta information about them to determine if they should be dropped.
And these are being eliminated. That is the drop flag will be entirely separate to the struct instance, and will only be injected into stack frames where there is a conditional branch in which a value is moved out in one, but not the other, e.g.
let x = some_value;
if condition { drop(x); } else { /* do nothing */ }
then `x` will get a drop flag as a single bit (or byte) on the stack. If the code is changed to
if condition { drop(x); } else { drop(x) }
there will be no drop flag, and no overhead.
Furthermore, placing the value on to the heap, e.g. `box some_value`, will not have an associated drop flag for `some_value`, that is, eliminating the byte that is currently stored with it.
- shadowmint 12y agoWhatever, there are still drop flags (on the stack instead, sure), and still dynamic runtime checks for drops. The points I was making is that 'zero cost' memory management isn't 100% zero cost. The drop checker does incur some basic dynamic runtime costs. To be 'zero cost' drop behaviour would be determined at compile time.
- dbaupp 12y agoThe behaviour is determined at compile time, with runtime cost only introduced if it is absolutely needed (when one branch drops, and another doesn't), and, even then, it can be avoided, by manually forcing a drop of the value in every branch.