Эффективное использование Hashmap
Я лично объявил бы, что он возвращает интерфейс, а не конкретный набор. Если Вы действительно хотите доступ списка, используйте IList . Иначе рассмотрите ICollection и IEnumerable .
3 ответа
Определенно B. Преимущество хеш-таблиц в том, что среднее количество сравнений за один поиск не зависит от размера.
Если вы разделите свою карту на N хэш-карт меньшего размера, вам придется искать в среднем половину из них для каждого запроса. Если меньшие хэш-карты имеют тот же коэффициент загрузки, что и большая карта, вы увеличите общее количество сравнений примерно в N / 2 раза.
И если меньшие хэш-карты имеют меньший коэффициент загрузки, вы трата памяти.
Все это предполагает случайное распределение ключей между меньшими хэш-картами. Если вы распределяете их в соответствии с какой-либо функцией ключа (например, строковым префиксом), то вы создали дерево , которое эффективно для некоторых приложений (например, автозаполнение в веб-формах).
Используются ли эти карты в логически разных местах? Например, у меня не было бы одной карты, содержащей пользователей, кешированные результаты запросов, регистраторы и т. Д., Просто потому, что вы знаете, что ключи не будут конфликтовать. Однако я бы в равной степени не разделил бы одну карту на несколько.
Сохраните одну хэш-карту для каждого логического сопоставления от ключа к значению.
В дополнение к ответу @Jon могут быть практические причины, по которым вы хотите поддерживать отдельные хеш-таблицы.
Если у вас есть отдельные таблицы для разных отображений, вы можете «очистить» каждое из отображений независимо; например, вызвав 'clear' или избавившись от ссылки на соответствующую таблицу.
Если отдельные таблицы содержат сопоставления с кэшированными записями, вы можете использовать разные стратегии для «устаревания» соответствующих записей.
Если приложение является многопоточность, использование отдельных таблиц может уменьшить конфликт блокировок и может (для некоторых архитектур процессоров) увеличить коэффициент попадания в кэш памяти процессора.