Библиотека Generic классов - ошибки, описание, вопросы, особенности использования и предложения - страница 35
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Почти невозможно и если нарветесь, доступ все равно сверх эффективный.
Коллизия при любом уровне эффективности - плохо. Спасибо за ответ. Учту.
Коллизия при любом уровне эффективности - плохо. Спасибо за ответ. Учту.
Хешмапов без коллизий по определению не бывает.
Вопрос по коллизиям. Возможно ли нарваться на коллизию в таком случае?
Если было произведено 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.