Sealed records inheriting from object should not have an EqualityContract

[KrisVandermotten]

Version Used: Visual Studio 16.8.1

Consider the following code:

public sealed record Point(int X, int Y);

Because

• Point's base class is object
• Point is sealed
• Point does not have a property in source code called EqualityContract

The GetHashCode() and Equals(Person) methods should be optimized to not use the private Type EqualityContract property.

The performance difference could be measurable, e.g. when sealed records are used as keys in dictionaries.

Furthermore, because

• Point has no members (in source code) accessing its private EqualityContract property

the private Type EqualityContract property is redundant and should not be generated. (In the unlike event there is code that depends on the property being there, e.g. using reflection, it can easily be added in source code by the developer explicitly.)

[CyrusNajmabadi]

The performance difference could be measurable

Measurements would be valuable.

it can easily be added in source code by the developer explicitly.)

That could break existing code on upgrade.

[alrz]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-08-24.md#omitting-unnecessary-synthesized-record-members

[KrisVandermotten]

Measurements would be valuable.

I ran several benchmarks using these two types:

sealed record PointRecord(int X, int Y);

sealed class PointClass : IEquatable<PointClass>
{
    public PointClass(int x, int y) => (X, Y) = (x, y);

    public int X { get; init; }
    public int Y { get; init; }

    public override int GetHashCode() =>
        EqualityComparer<int>.Default.GetHashCode(X) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(Y);

    public override bool Equals(object obj) => Equals(obj as PointClass);

    public bool Equals(PointClass other) =>
        other != null && EqualityComparer<int>.Default.Equals(X, other.X) && EqualityComparer<int>.Default.Equals(Y, other.Y);
}

As is to be expected, GetHashCode() is significantly faster for PointClass than for PointRecord:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System;
using System.Collections.Generic;

BenchmarkRunner.Run<Benchmark>();

public class Benchmark
{
    private readonly PointRecord pr = new PointRecord(7, 11);
    private readonly PointClass pc = new PointClass(7, 11);

    [Benchmark(Baseline = true)]
    public int PointRecordGetHashCode() => pr.GetHashCode();

    [Benchmark]
    public int PointClassGetHashCode() => pc.GetHashCode();
}

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-8550U CPU 1.80GHz (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=5.0.100
[Host] : .NET Core 5.0.0 (CoreCLR 5.0.20.51904, CoreFX 5.0.20.51904), X64 RyuJIT
DefaultJob : .NET Core 5.0.0 (CoreCLR 5.0.20.51904, CoreFX 5.0.20.51904), X64 RyuJIT

Method	Mean	Error	StdDev	Ratio	RatioSD
PointRecordGetHashCode	4.960 ns	0.0505 ns	0.0448 ns	1.00	0.00
PointClassGetHashCode	3.014 ns	0.0879 ns	0.0902 ns	0.61	0.02

Like I said, this is as expected: after all, calculating the hash code of an integer is basically a no-op. Obviously, we wouldn't see such a speed-up when the record contains a few string members. I'm sure we would see similar results when we benchmark the Equals method.

Where it get's interesting, is when we benchmark a simple algorithm using these types as keys in a dictionary:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System;
using System.Collections.Generic;

BenchmarkRunner.Run<Benchmark>();

public class Benchmark
{
    private readonly Dictionary<PointRecord, int> prdict = new();
    private readonly List<PointRecord> prkeys = new();

    private readonly Dictionary<PointClass, int> pcdict = new();
    private readonly List<PointClass> pckeys = new();

    public Benchmark()
    {
        for (int x = 0; x < 100; x++)
        {
            for (int y = 0; y < 100; y++)
            {
                prkeys.Add(new PointRecord(x, y));
                prdict[new PointRecord(x, y)] = x + y;

                pckeys.Add(new PointClass(x, y));
                pcdict[new PointClass(x, y)] = x + y;
            }
        }
    }

    [Benchmark(Baseline = true)]
    public int CalculationWithPointRecord()
    {
        int sum = 0;
        foreach (var key in prkeys)
        {
            sum += prdict[key];
        }
        return sum;
    }

    [Benchmark]
    public int CalculationWithPointClass()
    {
        int sum = 0;
        foreach (var key in pckeys)
        {
            sum += pcdict[key];
        }
        return sum;
    }
}

Method	Mean	Error	StdDev	Ratio	RatioSD
CalculationWithPointRecord	295.7 us	5.82 us	10.92 us	1.00	0.00
CalculationWithPointClass	278.3 us	5.56 us	10.17 us	0.94	0.05

We see only a 6% speed difference in a microbenchmark on types with an artificially high performance difference for their GetHashCode and Equals methods. Given the high standard deviations, one could argue there is hardly any difference at all.

It seems to me that these performance differences in themselves are not high enough to warrant a code change.

[CyrusNajmabadi]

It seems to me that these performance differences in themselves are not high enough to warrant a code change.

Agreed.

[KrisVandermotten]

@alrz

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-08-24.md#omitting-unnecessary-synthesized-record-members

Thanks for that link. It makes a lot of sense.