2020-08-29 00:08:51 +00:00
|
|
|
[package]
|
|
|
|
|
name = "bevy_utils"
|
2022-04-17 23:04:52 +00:00
|
|
|
version = "0.8.0-dev"
|
2021-10-27 00:12:14 +00:00
|
|
|
edition = "2021"
|
2020-08-29 00:08:51 +00:00
|
|
|
description = "A collection of utils for Bevy Engine"
|
|
|
|
|
homepage = "https://bevyengine.org"
|
|
|
|
|
repository = "https://github.com/bevyengine/bevy"
|
2021-07-23 21:11:51 +00:00
|
|
|
license = "MIT OR Apache-2.0"
|
2020-08-29 00:08:51 +00:00
|
|
|
keywords = ["bevy"]
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
2021-02-01 21:29:54 +00:00
|
|
|
ahash = "0.7.0"
|
2022-04-27 19:08:11 +00:00
|
|
|
tracing = { version = "0.1", default-features = false, features = ["std"] }
|
2020-11-22 00:38:24 +00:00
|
|
|
instant = { version = "0.1", features = ["wasm-bindgen"] }
|
2022-05-30 17:26:23 +00:00
|
|
|
uuid = { version = "1.1", features = ["v4", "serde"] }
|
Proper prehashing (#3963)
For some keys, it is too expensive to hash them on every lookup. Historically in Bevy, we have regrettably done the "wrong" thing in these cases (pre-computing hashes, then re-hashing them) because Rust's built in hashed collections don't give us the tools we need to do otherwise. Doing this is "wrong" because two different values can result in the same hash. Hashed collections generally get around this by falling back to equality checks on hash collisions. You can't do that if the key _is_ the hash. Additionally, re-hashing a hash increase the odds of collision!
#3959 needs pre-hashing to be viable, so I decided to finally properly solve the problem. The solution involves two different changes:
1. A new generalized "pre-hashing" solution in bevy_utils: `Hashed<T>` types, which store a value alongside a pre-computed hash. And `PreHashMap<K, V>` (which uses `Hashed<T>` internally) . `PreHashMap` is just an alias for a normal HashMap that uses `Hashed<T>` as the key and a new `PassHash` implementation as the Hasher.
2. Replacing the `std::collections` re-exports in `bevy_utils` with equivalent `hashbrown` impls. Avoiding re-hashes requires the `raw_entry_mut` api, which isn't stabilized yet (and may never be ... `entry_ref` has favor now, but also isn't available yet). If std's HashMap ever provides the tools we need, we can move back to that. The latest version of `hashbrown` adds support for the `entity_ref` api, so we can move to that in preparation for an std migration, if thats the direction they seem to be going in. Note that adding hashbrown doesn't increase our dependency count because it was already in our tree.
In addition to providing these core tools, I also ported the "table identity hashing" in `bevy_ecs` to `raw_entry_mut`, which was a particularly egregious case.
The biggest outstanding case is `AssetPathId`, which stores a pre-hash. We need AssetPathId to be cheaply clone-able (and ideally Copy), but `Hashed<AssetPath>` requires ownership of the AssetPath, which makes cloning ids way more expensive. We could consider doing `Hashed<Arc<AssetPath>>`, but cloning an arc is still a non-trivial expensive that needs to be considered. I would like to handle this in a separate PR. And given that we will be re-evaluating the Bevy Assets implementation in the very near future, I'd prefer to hold off until after that conversation is concluded.
2022-02-18 03:26:01 +00:00
|
|
|
hashbrown = { version = "0.11", features = ["serde"] }
|
2020-10-21 22:55:35 +00:00
|
|
|
|
|
|
|
|
[target.'cfg(target_arch = "wasm32")'.dependencies]
|
2022-05-30 17:26:23 +00:00
|
|
|
getrandom = {version = "0.2.0", features = ["js"]}
|
