Чому 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 сек набагато більше цифр, показаних у цій відповіді.
• Чи є кращий спосіб зберігати очки без дублікатів?

Є дві перф проблеми, викликані точковою структурою. Щось ви можете побачити, додавши Console.WriteLine(GC.CollectionCount(0));до тестового коду. Ви побачите, що для тестування на точку потрібно ~ 3720 колекцій, але для тесту рядків потрібно лише 18 колекцій. Не безкоштовно. Коли ви бачите, що тип значення викликає стільки колекцій, то вам потрібно зробити висновок "е-о, занадто багато боксу".

Суперечка полягає в тому, що HashSet<T>потрібно IEqualityComparer<T>виконати свою роботу. Оскільки ви його не надали, він повинен повернутися до повернутого EqualityComparer.Default<T>(). Цей метод може зробити гарну роботу для рядка, він реалізує IEquatable. Але не для Point, це тип, який виграє від .NET 1.0 і ніколи не отримував любові до генериків. Все, що він може зробити, це використовувати методи Object.

Інша проблема полягає в тому, що 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 разів швидше, легко обігравши тест на струну.

Основна причина падіння продуктивності - це все, що відбувається бокс (як уже пояснено у відповіді Ганса Пасанта ).

Крім того, алгоритм хеш-коду погіршує проблему, оскільки викликає більше дзвінків, Equals(object obj)таким чином збільшуючи кількість конверсій боксу.

Також зауважте, що хеш-кодPoint обчислюється x ^ y. Це призводить до дуже малої дисперсії у вашому діапазоні даних, і тому відра HashSetперенаселених - те, що не трапляється string, де дисперсія хешей набагато більша.

Ви можете вирішити цю проблему, застосувавши власну Pointструктуру (тривіальну) та використовуючи кращий хеш-алгоритм для очікуваного діапазону даних, наприклад, зміщуючи координати:

(x << 16) ^ y

Щоб отримати кілька корисних порад щодо хеш-кодів, прочитайте публікацію блогу Еріка Ліпперта .