-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Name component simplification #17582
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
Conversation
|
Since There's a serialized
|
I would like to ensure that we don't change the serialized format: this is critical enough that a manual impl is worth it. Swapping over to |
|
Oh, sorry for the confusion! I forgot which things use Reflect and which use Serialize, and that file threw me off. |
|
the current and not sure your benches are entirely good, at least for the equals/different variants, as they create the hashes in the bench. I think this should be part of the setup |


Objective
Namecomponent was built, it catch my attention how needlessly complex it was.PartialEqfor the case where both hashes are different, as it's assumed that both are Names are different.#[derive]Solution
Debug,Hash,PartialOrd,PartialEq,SerializeandDeserialize. Substituting them with#[derive]set()andmutate::<F: FnOnce(&mut String)>()with a simplerto_mut()Testing
cargo run -p ciLocallyPerfomance testing:
I was curious if the performance would suffer or improve compared to the previous implementation, so I've created some benchmarks to compare the
PartialEqimplementations (since it was the only place where the internal hash was used).It also tests how it would behave if a lot of
Name's are inserted in aHashSet.The benchmarks are not included in this PR, since I don't see really any value in benchmarking default
PartialEqin the future.The results are the following:
Which kind of shows that previous implementation is only better if somehow you create a ton of small
Name's, and compare them where internal strings are relatively small.Just to be clear, I don't think any of this benchmarks represents any real usage of the
Namecomponent, making the previous complex implementation harder to justify.Migration Guide
mutateandsetare replaced with ainto_mut()that returns a mutableString.