-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparison and hashing archetype::IdentifierRef
s by address
#160
Comments
The relevant part of the Line 409 in 9778eb3
A possible solution is to have another map in Furthermore, if the hash implementation for |
I've got a lot of this working, but I've hit a bit of a snag with the serialization part. Hashing based on address makes the serde tests super flakey. Like, unusably so. This is because addresses are not constant between runs, unlike values, and therefore the hashing is super inconsistent and the orders of multiple archetypes in serialization is unpredictable. I can get the tests for multiple archetypes to pass each about 4.125% of the time, which makes sense as there are four archetypes to be ordered. That also means that the chance of both flakey tests passing is about 0.0017%, which is basically unusable. Unfortunately, A possible solution is to test serialization and deserialization in these cases separately. The deserialization is straight-forward: any ordering of archetypes will result in equivalent deserializations. For serialization, we could possibly parse the It's unfortunate that |
I forgot that The other solution is to implement my own |
Currently, hashing is done by relying on the slice hash implementation: https://github.com/Anders429/brood/blob/master/src/archetype/identifier/mod.rs#L341. This eventually calls directly into
hash_slice
, which touches every element of the slice: https://doc.rust-lang.org/src/core/hash/mod.rs.html#237-245This is inefficient for the case of
IdentifierRef
, for most use cases. Within theArchetypes
map, the key is the uniqueIdentifierRef
(see here: https://github.com/Anders429/brood/blob/master/src/archetypes/mod.rs#L80-L84), which will always be unique both value-wise and address-wise. If twoIdentifierRef
s in this context have different addresses, they will also have different values, invariantly. This is ensured because a newIdentifier
, and its subsequentIdentifierRef
, will only be created if one does not already exist in the table for the given entity signature.This, however, does not apply to serialization. For example, this test case: https://github.com/Anders429/brood/blob/master/src/archetypes/impl_serde.rs#L406 provides the same archetype identifiers for multiple archetypes, and is expected to fail because they hash to the same thing. In this case, the hashing should be done based on value; if it is done based on address, the current logic can't catch the duplicate.
It seems there are also some edge cases in the
Clone
implementations, but I don't have time to investigate those right now.It would be great to change the usages that shouldn't care about the values to just pay attention to the addresses. This would be more efficient, I believe.
The text was updated successfully, but these errors were encountered: