Reference equality performance difference? ((object)obj1 == (object)obj2) vs. object.ReferenceEquals( obj1, obj2 )

Question

Is there extra overhead in using the object.ReferenceEquals method verses using ((object)obj1 == (object)obj2)?

In the first case, there would be a static method call involved, and in both cases some form of casting to an object would be involved.

Even if the compiler balances out those methods, what about inequality?

(object)obj != null

as compared to...

!object.ReferenceEquals(obj,null)

I suppose that at some point, a logical negation would occur, either within the != operator, or as applied to the result of the ReferenceEquals method. What do you think?

There's also the issue of readability to consider. ReferenceEquals seems clearer when checking equality, but for inequality, one might miss the ! preceding object.ReferenceEquals, whereas the != in the first variation is hard to overlook.

Answer 1

Is there extra overhead in using the object.ReferenceEquals method

No. The method directly contains the minimal IL description to perform the reference equality check (for the record: it's equivalent to VB's Is operator) and will often be inlined by the JIT (especially when targeting x64) so there's no overhead.

About readability: I personally think that object.ReferenceEquals is potentially more readable (even in the negated form) because it explicitly expresses its semantics. The cast to object may be confusing to some programmers.

I've just found an article discussing this. It prefers (object)x == y because the IL footprint is smaller. It argues that this might facilitate inlining of method X using this comparison. However (without any detailed knowledge of the JIT but logically and intuitively) I believe this is wrong: if the JIT behaves anything like an optimizing C++ compiler, it will consider the method after inlining the call to ReferenceEquals, so (for the sake of inlining method X) the memory footprint will be exactly the same either way.

That is to say: choosing one way over the other will have no impact whatsoever on the JIT and consequently on performance.

Answer 2

Contrary to answers here, I found (object) == faster than object.ReferenceEquals. As to how faster, very negligible!

Test bed:

I know you need reference equality check, but I'm including static object.Equals(,) method as well in case of classes where its not overriden.

Platform: x86; Configuration: Release build

class Person {
}

public static void Benchmark(Action method, int iterations = 10000)
{
    Stopwatch sw = new Stopwatch();
    sw.Start();
    for (int i = 0; i < iterations; i++)
        method();

    sw.Stop();
    MsgBox.ShowDialog(sw.Elapsed.TotalMilliseconds.ToString());
}

Test:

Person p1 = new Person();
Person p2 = new Person();
bool b;
Benchmark(() =>
{
    b = (object)p1 == (object)p2; //960 ~ 1000ms
    b = object.ReferenceEquals(p1, p2); //~ 1250ms
    b = object.Equals(p1, p2); //2100ms
    b = EqualityComparer<Person>.Default.Equals(p1, p2); //~4000ms

}, 100000000);

Person p1 = new Person();
Person p2 = null;
bool b;
Benchmark(() =>
{
    b = (object)p1 == (object)p2; //990 ~ 1000ms
    b = object.ReferenceEquals(p1, p2); // 1230 ~ 1260ms
    b = object.Equals(p1, p2); //1250 ~ 1300ms
    b = EqualityComparer<Person>.Default.Equals(p1, p2); //~3100ms

}, 100000000);

Person p1 = null;
Person p2 = null;
bool b;
Benchmark(() =>
{
    b = (object)p1 == (object)p2; //960 ~ 1000ms
    b = object.ReferenceEquals(p1, p2); //1260 ~ 1270ms
    b = object.Equals(p1, p2); //1180 ~ 1220ms
    b = EqualityComparer<Person>.Default.Equals(p1, p2); //~3100ms

}, 100000000);

Person p1 = new Person();
Person p2 = p1;
bool b;
Benchmark(() =>
{
    b = (object)p1 == (object)p2; //960 ~ 1000ms
    b = object.ReferenceEquals(p1, p2); //1260 ~ 1280ms
    b = object.Equals(p1, p2); //1150 ~ 1200ms
    b = EqualityComparer<Person>.Default.Equals(p1, p2); //3700 ~ 3800ms

}, 100000000);

object.Equals(,) calls ReferenceEquals internally and if they are not equal it would call the overriden virtual Equals method of the class, and hence you see the notice the speed difference.

Results were consistent in Debug configuration too...

As pointed out, emphasis should be on Readability/meaningfulness/revealing intent.

Answer 3

The overhead of Object.ReferenceEquals is only in loading the arguments, which will be JITted away in most scenarios. After that, both Object.ReferenceEquals and operator== come down to a single IL ceq operator. At worst, the difference will be insignificant.

More importantly, Object.ReferenceEquals is much more intention-revealing than (object)o1 == (object)o2. It states clearly in the code "I am testing for reference equality / identity", rather than hiding the intent under a bunch of casts.