When an IEqualityComparer<T>
compares to objects, it first compares their hashcodes. Only if they are equal the Equals
method is used to refine the comparison. So in your case it should at least hit Equals
twice.
To demonstrate what an EqualityComparer does I made a little code snippet in Linqpad:
void Main()
{
var ss = new string[] { "aa1", "bb1", "cc1" };
var zz = new string[] { "aa2", "aa3", "zz2", "cc2" };
var res = ss.Join(zz, o => o, i => i, (i, o) => i + o,
new SubstringComparer()).ToList();
}
public class SubstringComparer : IEqualityComparer<string>
{
public bool Equals(string left, string right)
{
string.Format("{0} - {1}", left, right).Dump();
return left.Substring(0,2) == right.Substring(0,2);
}
public int GetHashCode(string value)
{
value.Dump();
return value.Substring(0,2).GetHashCode();
}
}
So strings are equal if their first two characters are equal. The output is:
aa2
aa3
aa2 - aa3
zz2
cc2
aa1
aa2 - aa1
bb1
cc1
cc2 - cc1
And the resulting list:
aa1aa2
aa1aa3
cc1cc2
You see that first the second list is compared (I'm not sure why, by the way, maybe the hashcodes are cached) and then the pairs.
So when your GenericEqualityComparer
never hits Equals
it somehow always generates a unique hashcode, which I think should be a bug. If it not always uses Equals
, here is the explanation. And if you want a comparer to always use Equals
you should make it always return an identical hashcode (which is inefficient, of course).