Gave it a spin.

Relative and absolute differences compared to before #1708

Thanks. I still have to do that myself when I'm back on my dev machine. The way I read this is that on .NET 4.7, the dictionary adds a little bit of overhead, but with more tests and more depth, it becomes faster. But I was hoping to get a larger improvement here.

How did you build that comparison chart?

A potential bias with this benchmark is that it favors adding caches of types, as it reuses ComplexType over and over.

I manually created the comparison chart using a spreadsheet.

To my surprise, first checking the size of the referenceTypes and valueTypes collections gave us another 5% improvement. But then I started a dotTrace session on the benchmarks process and discovered that listing the properties and fields of a type were taking a big chunk of the time, so I added some more caching giving us another 30% improvement. I'm assuming that the number of types cached is never going to become a memory issue.

Are we sure that one cannot in any (reasonable) way modify any of referenceTypes, valueTypes, compareRecordsByValue or getDefaultEqualityStrategy?

I've thought about that as well, but given how the options are not reconfigured after the actual object graph comparison starts, it should be save.

Here's a valid example that breaks with caching of EqualityStrategy.

public class Class1
{
    [Fact]
    public void RunMeFirst()
    {
        new MyClass { Value = 1 }.Should().BeEquivalentTo(new MyClass { Value = 1 });
    }
}

// Non-parallel tests are typically run after all parallel tests
[Collection("AssertionOptionsSpecs")]
public sealed class Class2 : IDisposable
{
    public Class2()
    {
        AssertionOptions.AssertEquivalencyUsing(opt => opt.ComparingByValue<MyClass>());
    }

    [Fact]
    public void RunMeSecond()
    {
        new MyClass { Value = 1 }.Should().NotBeEquivalentTo(new MyClass { Value = 1 });
    }

    public void Dispose()
    {
        AssertionOptions.AssertEquivalencyUsing(_ => new EquivalencyAssertionOptions());
    }
}

public class MyClass
{
    public int Value { get; set; }
}

[CollectionDefinition("AssertionOptionsSpecs", DisableParallelization = true)]
public class AssertionOptionsSpecsDefinition { }

And the numbers for leaving out caching EqualityStrategy.

Here's a valid example that breaks with caching of EqualityStrategy.

Did you test this? I haven't tried myself yet, but I'm wondering how that could fail. The cache is per instance of the SelfReferenceEquivalencyAssertionOptions

I did and and just double checked.
Here's the flow of what's happening

class1.RunMeFirst
    GetEqualityStrategy(MyClass) -> cache miss
        getDefaultEqualityStrategy(type) -> cache miss
            strategy = type.HasValueSemantics() ? EqualityStrategy.Equals : EqualityStrategy.Members;
                EqualityStrategy.Members
    GetEqualityStrategy(MyClass) -> cache hit
    
Class2.ctor
    AssertionOptions.AssertEquivalencyUsing(opt => opt.ComparingByValue<MyClass>());

class2.RunMeSecond
    GetEqualityStrategy(MyClass) -> cache miss
        getDefaultEqualityStrategy(type) -> cache hit // here's the bug, as valueTypes has been changed since equalityStrategyCache was populated
            EqualityStrategy.Members
    GetEqualityStrategy(MyClass) -> cache hit

class2.Dispose
    AssertionOptions.AssertEquivalencyUsing(_ => new EquivalencyAssertionOptions());

I don't even get how you figured that out.

Anyway, I think I've fixed it now.