Я работаю над приложением с малой задержкой, которое всегда должно быть высокоэффективным.
Мне нужно найти какой-то индекс на основе строки, поэтому я использую c ++ unordered_map. Ограничения: -Только вставка и поиск, без удаления -key - строка, значение - int -Ожидается, что в unordered_map будет добавлено не более 1 миллиона записей.
Я устанавливаю резерв unordered_map на 1 миллион. Это хорошо, или мне следует зарезервировать на порядок на несколько% больше, чем ожидалось, чтобы избежать повторного хеширования? Могу ли я установить его на 1 миллион, или я должен установить большое простое число, близкое к 1 миллиону или около 2 степени.
Я использую хеш-функцию строки по умолчанию в c ++ std lib, которая оказывается murmur2. Мои ключи имеют длину от - 25 до 50 символов, и все они являются уникальными ключами, содержащими цифры, прописные буквы английского алфавита и символы _. Достаточно ли этой хэш-функции для равномерного распределения ключей или мне нужно предоставить лучшую хеш-функцию для unordered_map?
Будет ли unordered_map выделять пространство для 1 миллиона пар ключей, значений, а также для массива размером 1 миллион, когда я вызываю резерв или резерв, создается только массив этого размера, а пары ключей и значений выделяются динамически при вставке?
Насколько сильно перетаскивается динамическое выделение пар ключ-значение в куче при вставке? Тем более, что это большая хеш-таблица с множеством записей.
Из соображений производительности было бы неплохо реализовать мою собственную хеш-таблицу с памятью, предварительно выделенной для 1 миллиона записей в стеке или во время инициализации, или вышеупомянутые оптимизации unordered_map достаточно близки?
Есть ли способ заранее выделить память для ожидаемого количества записей в unorderd_map, чтобы избежать динамического выделения при вставке?
