No description
Find a file
2025-06-03 21:30:43 -04:00
benches autocode: **Commit Message:**``Bump uuidmap version to 0.1.3 and update benchmark for values_mut`**Explanation:**- The uuidmap package version in both Cargo.toml and Cargo.lock was updated from 0.1.2 to 0.1.3.- The values_mut benchmark in benches/benches.rs was modified to add 10,000 elements to the table instead of just 2, which likely provides a more comprehensive benchmark for the values_mut` function. 2025-03-22 08:05:12 +00:00
src implement ser/deser with csv, json and tsv. 2025-06-03 21:27:40 -04:00
.gitignore finish implementation. 2025-02-08 18:45:35 -05:00
Cargo.lock add ser/deser 2025-06-03 19:24:08 -04:00
Cargo.toml bump version 2025-06-03 21:30:43 -04:00
guidelines.md autocode: **Commit Message:**``Add values_mut benchmark and method to Table- Introduced a new benchmark values_mut_benchmark to measure the performance of mutating values in the Table.- Added a values_mut method to Table to allow mutable iteration over the contained values.- Updated the Table tests to include a test for values_mut.``This commit message succinctly describes the changes made, including the addition of a new benchmark and method, as well as the corresponding test. 2025-03-22 05:17:36 +00:00
LICENSE write readme at 1am 2025-02-09 00:56:07 -05:00
README.md minor change to test something 2025-02-09 03:08:11 -05:00

UuidMap

This is an ArrayHashMap (otherwise called "Dense Storage" or an enhanced "VecMap"). It is essentially a relational database table. This one is specialized to use a random u128 as the key, rather than a sequential index.

The performances are on-par with modern bitset-based entity-component-systems, while lagging behind archetypal ECS (~3x slower than legion).

However, it has the advantage that it does not constraint someone to follow the ECS pattern of entities and components, with anything else thrown into resources.

Rather, you can use this as a realtime relational database, suitable for game development and game engines. This means you can store assets, entities, components, resources and events all in the same type Table<T>. Having it this way cleans up the code, allows for predictable performance and, most importantly, allows for unified tooling. (In-game Table<ItemDefinition> editor, anyone?)

You can also use it anywhere you would use an in-memory database.

Where it makes sense to use it.

Where you have:

  1. High performance needs
  2. Need centralized data storage to avoid copies and/or pointers.
  3. Data that will be shared between many systems.
  4. Don't mind paying the (small) price of u128 indices in exchange for the consistency gain.

Thread Safety

The tables are not thread-safe, by design. You should be using another crate to orchestrate safe table access (no double mutable access, no reads during writes.)

For game engines, I recommend world_dispatcher, which I made for this purpose.

Complexities

  • Iterating: O(n). raw Vec<T>.
  • Inserting: O(n) amortized. 2x vec insert + 1x hashmap insert.
  • Deleting: O(1). two swap remove. one hashmap get.
  • Get element by key: O(1). hash of u128 + array access.