为什么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结构引发了两个性能问题。添加Console.WriteLine(GC.CollectionCount(0));到测试代码后，您会看到一些东西。您会看到Point测试需要〜3720个集合，而字符串测试只需要〜18个集合。不是免费的。当您看到一个值类型引发了如此多的集合时，您需要得出结论“呃，哦，太多拳击”。

问题在于HashSet<T>需要一项IEqualityComparer<T>工作来完成。由于您未提供，因此需要回退为EqualityComparer.Default<T>()。该方法可以很好地处理字符串，它实现了IEquatable。但是不是Point的一种，它是从.NET 1.0衍生出来的一种类型，从未得到泛型的热爱。它所能做的就是使用Object方法。

另一个问题是Point.GetHashCode（）在此测试中没有完成出色的工作，发生了太多的碰撞，因此它严重地锤击了Object.Equals（）。字符串具有出色的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倍，可以轻松击败字符串测试。

性能下降的主要原因是所有拳击动作（如汉斯·帕桑特的回答中所述）。

除此之外，哈希码算法使问题变得更糟，因为它引起更多的调用，Equals(object obj)从而增加了装箱转换的数量。

另请注意，的哈希码由Point计算x ^ y。这在您的数据范围内产生的分散很小，因此，的存储桶中的HashSet人口过多- string散布的散布要大得多的情况不会发生。

您可以通过实现自己的Point结构（平凡的）并针对期望的数据范围使用更好的哈希算法来解决该问题，例如通过移动坐标：

(x << 16) ^ y

有关哈希码的一些好的建议，请阅读Eric Lippert关于该主题的博客文章。