参考性能差异？ （（object）obj1 ==（object）obj2）vs. object.ReferenceEquals（obj1，obj2） [英] Reference equality performance difference? ((object)obj1 == (object)obj2) vs. object.ReferenceEquals( obj1, obj2 )
问题描述
在使用 object.ReferenceEquals 方法中使用（（object）obj1 ==（object）obj2）？
在第一种情况下，会涉及到一个静态方法调用，在这两种情况下，都会涉及到某个对象的转换。 / p>
即使编译器平衡了这些方法，不平等又会怎样？
<$与...相比，c $ c>（object）obj！= null
！object.ReferenceEquals（obj，null）
我假设在某一点上，在！=运算符内或者应用于ReferenceEquals方法的结果，将发生逻辑否定。你觉得怎么样？
还有一个问题是可读性要考虑。 ReferenceEquals在检查等式时似乎更清楚，但是对于不等式，可能会错过！ 之前的 object.ReferenceEquals ，而第一个变体中的 ！= 很难忽略。
在使用object.ReferenceEquals方法时有额外的开销
否。该方法直接包含执行引用相等性检查的最小IL描述（对于记录：它等同于VB的是运算符），并且通常由JIT内联（特别是当
关于可读性：我个人认为 object.ReferenceEquals 潜在地更可读（即使在否定形式），因为它显式地表达其语义。 对象可能会对某些程序员造成混淆。
我刚刚发现一篇文章讨论这个。它优选（object）x == y ，因为IL占用空间较小。它认为这可能有助于使用此比较的方法 X 的内联。但是（没有JIT的任何详细知识，但在逻辑和直观上）我相信这是错误的：如果JIT的行为像一个优化C ++编译器，它会考虑 后调用< c $ c> ReferenceEquals ，所以（为了内联方法 X ）内存占用将完全相同。
这就是说：选择一种方式对另一种方式不会对JIT产生任何影响，从而影响性能。
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.
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.
这篇关于参考性能差异？ （（object）obj1 ==（object）obj2）vs. object.ReferenceEquals（obj1，obj2）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
