EqualityComparer <T>. O padrão não é inteligente o suficiente
Eu estava lendo o código fonte deEqualityComparer<T>.Default
e descobriu que não é tão inteligente. Aqui está um exemplo
enum MyEnum : int { A, B }
EqualityComparer<MyEnum>.Default.Equals(MyEnum.A, MyEnum.B)
//is as fast as
EqualityComparer<int>.Default.Equals(0, 1)
enum AnotherEnum : long { A = 1L, B = 2L }
//is 8x slower than
EqualityComparer<long>.Default.Equals(1L, 2L)
A razão é óbvia no código-fonte do método privado no EqualityCompare
private static EqualityComparer<T> CreateComparer()
{
//non-important codes are ignored
if (c.IsEnum && (Enum.GetUnderlyingType(c) == typeof(int)))
{
return (EqualityComparer<T>) RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter((RuntimeType) typeof(EnumEqualityComparer<int>), c);
}
return new ObjectEqualityComparer<T>();
}
Nós podemos verEqualityComparer<int>.Default
,EqualityComparer<MyEnum>.Default
eEqualityComparer<long>.Default
obtenha um comparador sábio cujaEquals
método @ se parece com:
public static bool Equals(int x, int y)
{
return x == y; //or return x.Equals(y); here
//I'm not sure, but neither causes boxing
}
public static bool Equals(MyEnum x, MyEnum y)
{
return x == y; //it's impossible to use x.Equals(y) here
//because that causes boxing
}
Os dois acima sãointeligent, masEqualityComparer<AnotherEnum>.Default
é azarado, pelo método que podemos ver, finalmente, obtém umObjectEqualityComparer<T>()
, de quemEquals
método @ provavelmente se parece com:
public static bool Equals(AnotherEnum x, AnotherEnum y)
{
return x.Equals(y); //too bad, the Equals method is from System.Object
//and it's not override, boxing here!
//that's why it's so slow
}
Acho que esta condiçãoEnum.GetUnderlyingType(c) == typeof(int)
é inútil, se o tipo subjacente de uma enumeração for do tipo int, o método poderáconverte o comparador padrão de int para esta enumeração. Mas por que uma enum não pode durar muito? Não é tão difícil, eu acho? Alguma razão especial? Construindo um comparador comox == y
não é tão difícil para enum, certo? Por que, finalmente, dá uma lentaObjectEqualityComparer<T>
para enumerações (mesmo que funcione corretamente