Expand description
§Table
Implementation of a ArrayHashMap (also called MapVec or DenseStorage). It has good performance characteristics for things that matter: iterating, adding, removing, finding.
It is designed to resemble a database table, with the exception that keys are always uuids. Most of the time, the keys are randomly generated.
§Design
This is meant to be a replacement for the Entity-Component-System pattern. It can be used for much more, but I designed it in way to merge the architecture of component storages with resource storages. This makes it much easier to reason about how things work, along with requiring significantly less code to use and build upon.
§Uuid Keys
They were chosen because they don’t need a last_index counter, they don’t need O(n) to find a free slot, they won’t collide and they don’t cause fragmentation. Also, being forced to have a single type for all keys in a program/database makes things much easier to understand than having compound keys of strings and the like.
However, it does come at the cost of more memory usage, slightly lower performance and less opportunities for cheeky, application-specific optimizations. I believe that the advantages outweight the cost here.
§Performance
Performance loss has been minimized as much as possible.
In my benchmarks, the results show performance similar to bitset-based entity-component-systems, which are considered extremely fast (as of writing this.)
However, depending on how you link tables together, you will see different performance characteristics ranging from “literally iterating a Vec
§Caveats
If you don’t need iterating: Use HashMap.
If you don’t need finding by key: Use Vec.
If you need elements to be sorted: Use a BTree.
You may still use this in the first two cases, but do be aware that you are wasting performance and memory. This can be worthwhile for consistency sometimes.
Structs§
- Table
- See crate level documentation.