2016-09-26 2 views
2

Текущий у меня есть вложенный хэш. Ключ внутренней карты имеет очень большой диапазон, но внешний ключ карты имеет только 10 различных возможных строк.unordered_map vs vector + пользовательское хеширование для небольшого количества элементов

unordered_map<string, unordered_map<int, list<string>>> nestedHashMap; 

было бы более эффективным для меня, чтобы переключиться на

vector<unordered_map<int, list<string>>> 

и есть мой собственный хэш-функцию

static int hashFunc(string stringToBeHashed){ 
     switch(stringToBeHashed){ 
      case "example1": 
       return 0; 
      . 
      . 
      . 
      case "example10": 
       return 9; 
      default: 
       return -1; 
     } 
    } 

и сделать свой собственный хэширования перед каждым смотреть? Что касается сложности пространства, из-за того, что unordered_map является контейнером на основе узлов, я думаю, что этот векторный подход спасет мне некоторую память на каждом узле, требуемую unordered_map. Кроме того, я предполагаю, что внутренний хэш-файл гарантирует быстрый поиск, даже если ключ является int. Ключ имеет большой диапазон, поэтому я не думаю, что использование вектора здесь увеличило бы производительность. Правильно? Любые комментарии/советы будут оценены.

Память здесь не является проблемой.

+1

Пробуйте различные варианты и измеряйте их характеристики. Затем вернитесь и скажите всем остальным, чтобы мы могли все учиться. –

+0

Пока вы на нем, рассмотрите 'vector ' вместо 'list '. Результаты могут шокировать и смятение. – user4581301

ответ

0

В случае, если кто был интересно, сделал быстрое профилирование кода с

vector<unordered_map<int, list<string>> 
map<string, unordered_map<int, list<string>> 
unordered_map<string, vector<unordered_map<int, list<string>> 

вектора имел быстрое среднее время с последующим unordered_map с последующим картой.

2

Внутренний ключ карта имеет очень большой диапазон

Именно поэтому HashMap является правильный выбор здесь

, но внешний ключ карта имеет только 10 различных возможных строк

И там вы неправильно используете хэш.
Вместо этого замените его деревом (std::map).
(Да, вы можете выбрать std::vector, если вы хотите, чтобы написать функцию поиска самостоятельно, вы)
Кстати, вы не должны касаться пространств сложности темы, когда у вас есть только 10 элементов :) Update: цель
Вашего внешнего контейнера является в основном для хранения 10 элементов.
Это крошечное число, поэтому в теории вы можете выбрать все, что вы хотите (массив, дерево, хэш-таблица).
cotainer.
Итак, вы должны выбрать наилучшую посадку.
Варианты:

  • std::map: минимум код писать, сортирует элементы автоматически
  • std::vector: оптимальное использование пространства, но вы должны написать функцию просмотра самостоятельно, вы
  • std::hashmap: стрельба из пушки в воробьи. Вам не нужно 99% функциональности, которую он предоставляет. Это contaner имеет другое назначение, чем ваша
+0

10 элементов как в 10 возможных элементах для внешнего хэшмапа. Я имею дело с миллионами данных, которые хэшируются в 10 разных местах, а затем внутренний хэш-файл - это то, где вещи становятся довольно большими. Но почему я предпочитаю карту над unordered_map в случае 10 возможных отображений? –

+0

@DavidYuan см. Обновленный ответ –

+0

имеет смысл. Благодаря! –