HashSet <Point>がHashSet <string>よりもはるかに遅いのはなぜですか？

重複を許可せずにいくつかのピクセル位置を保存したかったので、最初に頭に浮かぶのは、HashSet<Point>または同様のクラスです。しかし、これはのようなものに比べて非常に遅いようHashSet<string>です。

たとえば、次のコード：

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

約22.5秒かかります。

次のコード（明らかな理由からこれは適切な選択ではありません）は1.6秒しかかかりません。

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

だから、私の質問は：

• その理由はありますか？私はこの回答をチェックしましたが、22.5秒はその回答に示されている数値よりもはるかに長くなっています。
• 重複なしでポイントを保存するより良い方法はありますか？

Point構造体によって引き起こされる2つのパフォーマンス問題があります。Console.WriteLine(GC.CollectionCount(0));テストコードに追加したときに表示されるもの。ポイントテストには最大3720コレクションが必要ですが、文字列テストには最大18コレクションしか必要ないことがわかります。無料ではありません。値型が非常に多くのコレクションを誘発する場合、「ええと、あまりにも多くのボクシング」を結論付ける必要があります。

問題は、それHashSet<T>がIEqualityComparer<T>その仕事を成し遂げるために必要です。提供していないため、から返されたものにフォールバックする必要がありますEqualityComparer.Default<T>()。そのメソッドは文字列に対して適切に機能し、IEquatableを実装します。ただし、Pointの場合はそうではありません。.NET1.0に似ているタイプであり、ジェネリックに愛されることはありません。Objectメソッドを使用するだけで実行できます。

もう1つの問題は、このテストではPoint.GetHashCode（）が優れたジョブを実行せず、衝突が多すぎるため、Object.Equals（）にかなりの負荷がかかることです。Stringには、優れたGetHashCode実装があります。

HashSetに優れた比較機能を提供することで、両方の問題を解決できます。このように：

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

そしてそれを使う：

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

そして現在では約150倍高速になり、ストリングテストを簡単に打ち負かしています。

パフォーマンスの低下の主な理由は、ボクシングが進行していることです（Hans Passantの回答ですでに説明されています）。

それとは別に、ハッシュコードアルゴリズムは問題をさらに悪化させます。それは、より多くの呼び出しを引き起こしEquals(object obj)、ボクシング変換の量を増やすためです。

のハッシュコードPointはによって計算されることにも注意してくださいx ^ y。これにより、データ範囲で分散がほとんど発生しないため、のバケットHashSetが過密stringになります。これは、で発生しないもので、ハッシュの分散がはるかに大きくなります。

独自のPoint構造体（自明）を実装し、予想されるデータ範囲に対してより優れたハッシュアルゴリズムを使用することで、たとえば座標をシフトすることで、この問題を解決できます。

(x << 16) ^ y

ハッシュコードに関するいくつかの良いアドバイスについては、件名に関するEric Lippertのブログ投稿をご覧ください。