2

Closed

Array comparison is SLOW

description

I have a quite old laptop, so probably in a 30GHZ desktop it would be different, BUT:

Release Mode, without Visual Studio, xUnit graphical runner 4.0.30319.488 at 32 bits
// 21 seconds
Assert.Equal(new byte[10 * 1024 * 1024], new byte[10 * 1024 * 1024]);

// 6 seconds
Assert.Equal(new byte[10 * 1024 * 1024], new byte[10 * 1024 * 1024], EqualityComparer<byte>.Default);

// 0.3 seconds
Assert.True(new byte[10 * 1024 * 1024].SequenceEqual(new byte[10 * 1024 * 1024]));

// 0.3 seconds
Assert.True(new byte[10 * 1024 * 1024].SequenceEqual(new byte[10 * 1024 * 1024], EqualityComparer<byte>.Default));
I DO think it's a little slow for a 10mb comparison of two equal arrays.
Closed Aug 18, 2013 at 5:15 PM by BradWilson
This is an edge case. You should write your own assertion to deal with this rather than rely on the general purpose assertion.

comments

BradWilson wrote May 29, 2013 at 2:47 PM

The first two do something the second two don't: tell you at exactly which point in the array that the sequences diverge.

If this information isn't valuable to you, then use one of the latter two asserts.

It doesn't seem like a good idea for us to optimize for 10-million member arrays while killing valuable features that the rest of the community likes and relies upon.

xanatos wrote May 29, 2013 at 3:07 PM

99% of the time the tests should pass, so you could calculate the difference only on failure. Something like:
static void Equal(IEnumerable<T> val1, IEnumerable<T> val2)
{
    IList<T> val1l = (val1 as IList<T>) ?? val1.ToList();
    IList<T> val2l = (val2 as IList<T>) ?? val2.ToList();

    if (val1l.SequenceEqual(val2l))
    {
        return;
    }

    EqualSlow(val1l, val2l);
}