Perché HashSet <Point> è molto più lento di HashSet <string>?

Volevo memorizzare alcune posizioni di pixel senza consentire i duplicati, quindi la prima cosa che mi viene in mente è HashSet<Point>o classi simili. Tuttavia, questo sembra essere molto lento rispetto a qualcosa di simile HashSet<string>.

Ad esempio, questo codice:

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));
        }
    }
}

dura circa 22,5 secondi.

Mentre il codice seguente (che non è una buona scelta per ovvi motivi) richiede solo 1,6 secondi:

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);
        }
    }
}

Quindi, le mie domande sono:

• C'è una ragione per questo? Ho controllato questa risposta , ma 22,5 secondi è molto più dei numeri mostrati in quella risposta.
• Esiste un modo migliore per archiviare punti senza duplicati?

Ci sono due problemi perf indotti dalla struttura Point. Qualcosa che puoi vedere quando aggiungi Console.WriteLine(GC.CollectionCount(0));al codice di test. Vedrai che il test Point richiede ~ 3720 raccolte ma il test stringa richiede solo ~ 18 raccolte. Non gratis Quando vedi un tipo di valore indurre così tante raccolte allora devi concludere "uh-oh, troppa boxe".

In questione è che ha HashSet<T>bisogno di un IEqualityComparer<T>per fare il suo lavoro. Dato che non ne hai fornito uno, deve ricorrere a uno restituito da EqualityComparer.Default<T>(). Questo metodo può fare un buon lavoro per la stringa, implementa IEquatable. Ma non per Point, è un tipo che si rifà a .NET 1.0 e non ha mai avuto l'amore dei generici. Tutto ciò che può fare è usare i metodi Object.

L'altro problema è che Point.GetHashCode () non fa un lavoro stellare in questo test, troppe collisioni, quindi martella Object.Equals () piuttosto pesantemente. String ha un'eccellente implementazione di GetHashCode.

È possibile risolvere entrambi i problemi fornendo a HashSet un buon comparatore. Come questo:

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 usalo:

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

Ed è ora circa 150 volte più veloce, battendo facilmente il test delle stringhe.

Il motivo principale del calo delle prestazioni è tutto il pugilato in corso (come già spiegato nella risposta di Hans Passant ).

A parte questo, l'algoritmo del codice hash aggrava il problema, perché provoca più chiamate per Equals(object obj)aumentare la quantità di conversioni di boxe.

Si noti inoltre che il codice hash diPoint viene calcolato da x ^ y. Questo produce pochissima dispersione nel tuo intervallo di dati, e quindi i secchi di HashSetsono sovrappopolati - qualcosa che non accade con string, dove la dispersione degli hash è molto più grande.

Puoi risolvere quel problema implementando la tua Pointstruttura (banale) e usando un algoritmo di hash migliore per il tuo intervallo di dati previsto, ad esempio spostando le coordinate:

(x << 16) ^ y

Per qualche buon consiglio quando si tratta di codici hash, leggi il post sul blog di Eric Lippert sull'argomento .