Hash faster by not using derive #775

New issue

Closed

opened 2024-12-12 16:16:41 -06:00 by jrose-signal · 2 comments

jrose-signal commented

2024-12-12 16:16:41 -06:00

(Migrated from github.com)

Uuid currently uses derive(Hash), but this calls through to an array's default implementation, which in turn calls to the implementation for slices, which includes a length prefix and goes element by element. Instead, it could just call state.write(&self.0) directly.

Uuid currently uses `derive(Hash)`, but this calls through to an array's default implementation, which in turn calls to the implementation for *slices*, which includes a length prefix and goes element by element. Instead, it could just call `state.write(&self.0)` directly.

KodrAus commented

2024-12-13 03:49:28 -06:00

(Migrated from github.com)

The Hash trait doesn’t guarantee stability of hashes unless you have control over both the hasher and type being hashed, so I think we should be able to make this change.

It’s technically unrelated, but what we can’t unfortunately do is change how we compute hashes in v1, v3, or v5 UUIDs, or else we’d start computing a different UUID for the same input.

The `Hash` trait doesn’t guarantee stability of hashes unless you have control over both the hasher and type being hashed, so I think we should be able to make this change. It’s technically unrelated, but what we can’t unfortunately do is change how we compute hashes in v1, v3, or v5 UUIDs, or else we’d start computing a different UUID for the same input.

jrose-signal commented

2024-12-13 11:47:08 -06:00

(Migrated from github.com)

That's fine, those already pass the bytes directly. (And they are fully specified by the UUID standard, so they're either correct or wrong as they are.)