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.CompareToand the comparison operators.Might be more useful when comparing and orderign
Guids, especially now withGuid.CreateVersion7where the first 4-bits is a unix timestamp.Benchmark on x64 below, ,
Guids biffer on bits 33-48 (1 being MSB). Hopefully these are OK with regards to improvements (especially whenGuids differ on bits 1-32, which should be more likely).