-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Optimize Guid comparisons #104610
Optimize Guid comparisons #104610
Conversation
using BenchmarkDotNet.Attributes;
public class Perf
{
public static IEnumerable<object[]> Values()
{
yield return [
new Guid("EE268EB3-1E8F-4F76-87D7-6A5A43983CF4"),
new Guid("69F1C1B8-E6FE-4494-A536-BBFAC3429AD3")];
}
[Benchmark, ArgumentsSource(nameof(Values))]
public int Guid_CompareTo(Guid left, Guid right) => left.CompareTo(right);
} |
Benchmark results on Intel
|
This is a significant reduction in readability for what is at most a 1.5ns savings. I don't think the change is justifiable. It would likely be beneficial to see what the perf difference would be if we instead did:
This would reduce the total number of compares to 4 without making the code significantly more complex. |
V7 (G/U)uids have time-based ordering, and there are a lot of usage scenarios for them. IEnumerable<T> Shuffle<T>(IEnumerable<T> sequence) => sequence.OrderBy(x => Guid.NewGuid()); Are any regressions observed here? |
Got it.
I just tried this but there were unfortunately bigger regressions. Closing the PR. |
Optimization of
Guid.CompareTo
and the comparison operators.Might be more useful when comparing and orderign
Guid
s, especially now withGuid.CreateVersion7
where the first 4-bits is a unix timestamp.Benchmark on x64 below, ,
Guid
s biffer on bits 33-48 (1 being MSB). Hopefully these are OK with regards to improvements (especially whenGuid
s differ on bits 1-32, which should be more likely).