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
{{ message }}
This repository has been archived by the owner on Nov 8, 2023. It is now read-only.
Is there any reason to use the generational-arena over the slotmap crate?
AFAICT the latter existed first and is a superset, featuring a compact hop-representation for faster iteration in the presence of large holes in the collection and secondary maps to implement ECS-style associated data.
The only benefit I see is that generational-arena uses zero unsafe code. However, slotmap's usage of unsafe code is justified to use a more compact representation. The LSB of the slotmap generation is the tag indicating the state of the slot, instead of a full 1-byte (or 8-bytes if it gets padded) for the enum discriminate.
crate
size
max reuse per slot
slotmap
4 + max(size_of::<T>(), 4)
2^31
generational arena
(1 or 8) + 8 + size_of::<T>()
2^64
I'm pretty sure it is safe to say that a 64-bit generation tag is overkill? But if someone needs more than 31-bits, it would be trivial to tweak slotmap to use a type parameter such that its consumers can opt for 63-bits instead. However, this might not be necessary as the slotmap author wants to avoid hot slots
The text was updated successfully, but these errors were encountered:
The talk that sparked the creation of this crate mentioned slotmap with the desire for secondary maps, which it didn't have at the time. Generational arena does not satisfy that request.
I'm kind of wondering this too - I don't want to diminish your work or anything, because it's always cool when someone puts effort into making something.. but I was really confused for a full 10 minutes about how this crate was different from the slotmap crate that was mentioned in the very same talk that inspired this crate, according to the docs.
Two of slotmap's core types, SlotMap and HopSlotMap require value types to be Copy on stable Rust. That's a pretty big downside and is one of the reasons why I have used generational-arena instead.
@LPGhatguy In the upcoming version of slotmap that will no longer be the case and you can use any type on stable Rust. This is because ManuallyDrop<T> where T is non-Copy is now allowed in unions on stable.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is there any reason to use the
generational-arena
over theslotmap
crate?AFAICT the latter existed first and is a superset, featuring a compact hop-representation for faster iteration in the presence of large holes in the collection and secondary maps to implement ECS-style associated data.
The only benefit I see is that
generational-arena
uses zero unsafe code. However, slotmap's usage of unsafe code is justified to use a more compact representation. The LSB of the slotmap generation is the tag indicating the state of the slot, instead of a full 1-byte (or 8-bytes if it gets padded) for the enum discriminate.4 + max(size_of::<T>(), 4)
2^31
(1 or 8) + 8 + size_of::<T>()
2^64
I'm pretty sure it is safe to say that a 64-bit generation tag is overkill? But if someone needs more than 31-bits, it would be trivial to tweak
slotmap
to use a type parameter such that its consumers can opt for 63-bits instead. However, this might not be necessary as the slotmap author wants to avoid hot slotsThe text was updated successfully, but these errors were encountered: