Wrong assumption about slow ValueType.Equals method

[jinek]

The article says:

The System.ValueType implementation of Equals uses reflection because it must be able to determine what the fields are in any struct.

But if we look at the code:

We can see, that it does bitwise comparison if all fields are also value types.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 433a56c8-1c93-32fb-eb1d-8395a9760c65
• Version Independent ID: e3f35410-f243-4309-1436-89ade7a34d19
• Content: Objects - C# Programming Guide
• Content Source: docs/csharp/programming-guide/classes-and-structs/objects.md
• Product: dotnet-csharp
• Technology: csharp-fundamentals
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

[BillWagner]

Thanks for noting this @jinek

We need to revisit much our of performance guidance to reflect many of the performance improvements done for .NET Core. This is one optimization we need to discuss.

[jinek]

@BillWagner But this is not optimization for .net core. This is the way of comparison since the .NET 2.0

[KalleOlaviNiemitalo]

We can see, that it does bitwise comparison if all fields are also value types.

This optimization is prevented by:

• Padding bytes, e.g. in struct S { int a; byte b; }.
• Any field whose type is a reference type.
• Any field whose type is System.Single or System.Double.
• Any field whose type overrides Equals(object) and is not primitive.
• Any field whose type overrides GetHashCode() and is not primitive.

DateTime, Decimal, Nullable<T>, and ValueTuple types override Equals(object) and are not primitive, so they prevent the optimization.

enum types do not prevent the optimization. Perhaps the CLR considers them as inheriting Equals(object) and GetHashCode() from System.Enum rather than overriding those methods themselves. (I did not test enum types with floating-point underlying types, though.)

using System;
using System.Reflection;

namespace ValueTypeEquals
{
    struct S
    {
        DayOfWeek a;
    }

    class Program
    {
        static void Main(string[] args)
        {
            var canCompareBits = typeof(ValueType)
                .GetMethod("CanCompareBits", BindingFlags.Static | BindingFlags.NonPublic)
                .CreateDelegate<Func<object, bool>>();

            Console.WriteLine($"CCB(S): {canCompareBits(default(S))}");
        }
    }
}

[jinek]

This optimization is prevented by:

Thanks for info. Does this information changes current topic?

Now I'm also thinking about boxing when using ValueType.Equals(object). Probably it makes to mention in the article also? Because if we want to be as fast as possible we should avoid boxing, right?

I've also seen this interesting topic: https://devblogs.microsoft.com/premier-developer/performance-implications-of-default-struct-equality-in-c/

[KalleOlaviNiemitalo]

I think the current documentation is not strictly wrong, as the ValueType.CanCompareBits call could already be considered reflection. The behavior could be described in more detail but doing so might distract the developer from the more important things. The page already links to How to define value equality for a type (C# Programming Guide), which in turn links to IEquatable<T> Interface; if the developer follows the guidelines on those pages, then the equality comparisons will avoid runtime reflection and unnecessary boxing.

[jinek]

I think the current documentation is not strictly wrong, as the ValueType.CanCompareBits call could already be considered reflection.

Agree, it is not strictly 100% wrong. But CanCompareBits uses caching as I see https://github.com/dotnet/coreclr/blob/2583ce936776a0eac31df904e41d5119840c203b/src/vm/comutilnative.cpp#L2016
And if we are talking about one call then JIT compilation happens same time, which eventually comes to "use c++ for better performance".

The behavior could be described in more detail but doing so might distract the developer from the more important things. The page already links to How to define value equality for a type (C# Programming Guide), which in turn links to IEquatable Interface; if the developer follows the guidelines on those pages, then the equality comparisons will avoid runtime reflection and unnecessary boxing.

My point is exactly that it already distracts from importangs things.
Default implementation gives the possibility not to write additional code of comparison.
And if our value-type participates in iterations and we want to optimize it, then we should not use Equals at all, instead we should jump to How to define value equality for a type section immediately.

Also it switches the context to classes:

Which confuses. Readers of this guidelines probably don't have clear understanding that any struct is also class.

Thus I'm offering to re-phrase that like:

The System.ValueType implementation of Equals uses boxing and reflection in some cases. Jump to How to define value equality for a type if you want to provide an efficient equality algorithm that is specific to your type.