Por que o HashSet <Point> é muito mais lento que o HashSet <string>?

Eu queria armazenar algumas localizações de pixels sem permitir duplicatas, então a primeira coisa que vem à mente é HashSet<Point>ou classes semelhantes. No entanto, isso parece ser muito lento em comparação com algo comoHashSet<string> .

Por exemplo, este código:

HashSet<Point> points = new HashSet<Point>();
using (Bitmap img = new Bitmap(1000, 1000))
{
    for (int x = 0; x < img.Width; x++)
    {
        for (int y = 0; y < img.Height; y++)
        {
            points.Add(new Point(x, y));
        }
    }
}

leva cerca de 22,5 segundos.

Enquanto o código a seguir (que não é uma boa escolha por razões óbvias) leva apenas 1,6 segundos:

HashSet<string> points = new HashSet<string>();
using (Bitmap img = new Bitmap(1000, 1000))
{
    for (int x = 0; x < img.Width; x++)
    {
        for (int y = 0; y < img.Height; y++)
        {
            points.Add(x + "," + y);
        }
    }
}

Então, minhas perguntas são:

• Existe uma razão para isso? Eu verifiquei esta resposta , mas 22,5 segundos é muito mais do que os números mostrados nessa resposta.
• Existe uma maneira melhor de armazenar pontos sem duplicatas?

Existem dois problemas de desempenho induzidos pela estrutura Point. Algo que você pode ver quando adicionaConsole.WriteLine(GC.CollectionCount(0)); ao código de teste. Você verá que o teste de ponto requer ~ 3720 coleções, mas o teste de cadeia precisa apenas de ~ 18 coleções. Não de graça. Quando você vê um tipo de valor induzir tantas coleções, precisa concluir "uh-oh, muito boxe".

O problema é que HashSet<T>precisa de um IEqualityComparer<T>para fazer seu trabalho. Como você não forneceu um, ele precisa retornar ao retornado EqualityComparer.Default<T>(). Esse método pode fazer um bom trabalho para string, implementa IEquatable. Mas não para o Point, é um tipo que remete ao .NET 1.0 e nunca recebeu o amor dos genéricos. Tudo o que você pode fazer é usar os métodos Object.

A outra questão é que Point.GetHashCode () não faz um trabalho estelar neste teste, muitas colisões, então martela muito o Object.Equals (). String possui uma excelente implementação GetHashCode.

Você pode resolver os dois problemas fornecendo ao HashSet um bom comparador. Como este:

class PointComparer : IEqualityComparer<Point> {
    public bool Equals(Point x, Point y) {
        return x.X == y.X && x.Y == y.Y;
    }

    public int GetHashCode(Point obj) {
        // Perfect hash for practical bitmaps, their width/height is never >= 65536
        return (obj.Y << 16) ^ obj.X;
    }
}

E use-o:

HashSet<Point> list = new HashSet<Point>(new PointComparer());

E agora é 150 vezes mais rápido, superando facilmente o teste de cordas.

A principal razão para a queda no desempenho é todo o boxe (como já explicado na resposta de Hans Passant ).

Além disso, o algoritmo de código hash piora o problema, porque causa mais chamadas para Equals(object obj) aumentar a quantidade de conversões de boxe.

Observe também que o código hash dePoint é calculado por x ^ y. Isso produz muito pouca dispersão no seu intervalo de dados e, portanto, os depósitos HashSetsão superpovoados - algo que não acontece string, onde a dispersão dos hashes é muito maior.

Você pode resolver esse problema implementando sua própria Pointestrutura (trivial) e usando um algoritmo de hash melhor para o intervalo de dados esperado, por exemplo, deslocando as coordenadas:

(x << 16) ^ y

Para alguns bons conselhos sobre códigos de hash, leia o post de Eric Lippert no blog sobre o assunto .