Вопрос по коллизиям. Возможно ли нарваться на коллизию в таком случае?
Если было произведено 27 000 записей.
Постоянно будете нарыватся, особенно при росте (ресайзе) коллекции. Так как хешь дополнительно обрезается до номера банда, а их всегда ограниченное количество (в идеале равное capacity).
От сюда выводы:
1. Для map важна не криптостойкость хеш-функции, важна ее скорость. Хеш функции достаточно обеспечить хороший рандом и все.
2. Ресайза лучше избегать любыми способами. Основную просадку вносит именно ресайз. а не коллизии хеш-функции. Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
3. Колизии - это штатный механизм compaction. Через коллизии реализуется возможность хранения трех записей с id допустим 159, 4'569'209, 29'459'876 в массиве длины три, а не длины 30 000 000, пусть даже последние два значения оба попадут в банд с индексом 2.
2. Ресайза лучше избегать любыми способами. Основную просадку вносит именно ресайз. а не коллизии хеш-функции. Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
Пожалуйста, покажите на примере.
Использую пока только это.
//+------------------------------------------------------------------+//| Adds the specified key and value to the map. |//+------------------------------------------------------------------+template<typename TKey,typename TValue>
bool CHashMap::Add(TKey key,TValue value);
//+------------------------------------------------------------------+//| Gets the value associated with the specified key. |//+------------------------------------------------------------------+template<typename TKey,typename TValue>
bool CHashMap::TryGetValue(TKey key,TValue &value);
Когда создаете коллекцию CHashMap используйте один из конструкторов, принимающий параметр capacity. Что происходит с производительностью при ресайзе смотрите мою статью про CDicionary. Там полный разбор этого алгоритма.
Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
На примере выше попробовал выставлять capacity через конструктор. С определенного значения capacity пример начинает работать правильно.
Почти невозможно и если нарветесь, доступ все равно сверх эффективный.
Коллизия при любом уровне эффективности - плохо. Спасибо за ответ. Учту.
Коллизия при любом уровне эффективности - плохо. Спасибо за ответ. Учту.
Хешмапов без коллизий по определению не бывает.
Вопрос по коллизиям. Возможно ли нарваться на коллизию в таком случае?
Если было произведено 27 000 записей.
Постоянно будете нарыватся, особенно при росте (ресайзе) коллекции. Так как хешь дополнительно обрезается до номера банда, а их всегда ограниченное количество (в идеале равное capacity).
От сюда выводы:
1. Для map важна не криптостойкость хеш-функции, важна ее скорость. Хеш функции достаточно обеспечить хороший рандом и все.
2. Ресайза лучше избегать любыми способами. Основную просадку вносит именно ресайз. а не коллизии хеш-функции. Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
3. Колизии - это штатный механизм compaction. Через коллизии реализуется возможность хранения трех записей с id допустим 159, 4'569'209, 29'459'876 в массиве длины три, а не длины 30 000 000, пусть даже последние два значения оба попадут в банд с индексом 2.
2. Ресайза лучше избегать любыми способами. Основную просадку вносит именно ресайз. а не коллизии хеш-функции. Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
Пожалуйста, покажите на примере.
Использую пока только это.
Пожалуйста, покажите на примере.
Использую пока только это.
Когда создаете коллекцию CHashMap используйте один из конструкторов, принимающий параметр capacity. Что происходит с производительностью при ресайзе смотрите мою статью про CDicionary. Там полный разбор этого алгоритма.
Обнаружил очень необычное поведение CHashMap.
Получается, что идет якобы добавление ключа, но прочесть по нему ничего нельзя. Однако, стоит ключ добавить повторно, как он становится читаемым!
Это БАГ?
Если в примере цену 1.75141 заменить на другую, то будет работать правильно.
ЗЫ Было адски тяжело без дебага выявить это поведение в огромном коде и создать столь лаконичный пример.
Всегда при возможности инициализируйте коллекцию с предустановленным количеством элементов. Даже если не знаете их точно, указывайте примерное количество - это окажет большое подспорье алгоритму.
На примере выше попробовал выставлять capacity через конструктор. С определенного значения capacity пример начинает работать правильно.
Но думаю, это совпадение.
Обнаружил очень необычное поведение CHashMap.
Получается, что идет якобы добавление ключа, но прочесть по нему ничего нельзя. Однако, стоит ключ добавить повторно, как он становится читаемым!
Это БАГ?
Если в примере цену 1.75141 заменить на другую, то будет работать правильно.
ЗЫ Было адски тяжело без дебага выявить это поведение в огромном коде и создать столь лаконичный пример.
Исправлено, будет в сегодняшнем релизе.
Спасибо! Вижу правку.
На примере выше попробовал выставлять capacity через конструктор. С определенного значения capacity пример начинает работать правильно.
Но думаю, это совпадение.
Да там глюк на глюке. Я бы настоятельно не рекомендовал использовать Generic.