search

mlua-rs / rlua

High level Lua bindings to Rust
Other
1.73k stars 115 forks source link

perf: faster HashMap with TypeId keys #259

Closed Purpzie closed 9 months ago

Purpzie commented 2 years ago

TypeIds are already hashes from the compiler, so they don't need to be hashed again. I've added a dummy hasher which just passes the TypeId through without modifying it.

For example, the tracing-subscriber crate does the same thing: https://github.com/tokio-rs/tracing/blob/3517552c319a22c108d423ca9a1675e632f616a3/tracing-subscriber/src/registry/extensions.rs#L12-L34

SoniEx2 commented 2 years ago

relevant: https://github.com/rust-lang/rust/issues/10389

Purpzie commented 2 years ago

@SoniEx2 There doesn't seem to be a way to avoid that in the first place, since it's a problem in the compiler itself.

SoniEx2 commented 2 years ago

the point is "stop relying on current implementation details".

like sure, use a faster hasher. but don't break if TypeId changes.

(not panicking/doing nothing in write would be a good start, but would leave hashes as 0. it'd still work if TypeId changed at least, even if a lot slower due to hash collisions. alternatively having a slow path write and a fast path write_u64 would work.)

jugglerchris commented 2 years ago

Hi @Purpzie , Thanks for the contribution! I'm certainly open to performance improvements if they're correct and significant enough to offset any extra complexity. Have you measured the difference in performance (i.e. is hashing typeids a significant overhead)?