unordered_map vs vector +少量元素的自定義散列

當前我有一個嵌套的散列表。內部映射鍵具有非常大的範圍，但外部映射鍵只有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。關鍵有很大的範圍，所以我不認爲在這裏使用矢量會提高性能。對？任何意見/提示，將不勝感激。

內存在這裏不是問題。

來源

2016-09-26 David Yuan

嘗試各種變化並測量其性能。然後回來告訴其他人，這樣我們都可以學習。 –

當你在它的時候，考慮'矢量'來代替'list '。結果可能會令人震驚和沮喪。 – user4581301

如果有人想知道不同的目的，做了一個簡單的代碼分析與

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

載體具有最快的平均時間，隨後unordered_map其次是地圖。

來源

2016-09-27 05:41:33

內地圖鍵有一個非常大的範圍

這正是爲什麼HashMap的是一個正確的選擇在這裏

但外部映射按鍵只有10種不同的可能的字符串

在那裏你濫用hashmap。
改爲用樹（std::map）代替。
（是的，你可以選擇std::vector如果你想編寫一個查詢功能youself）
順便說一句，你不應該與空間複雜度的話題有關，當你只有10個元素:) 更新：
你的外容器的目的是基本上可以存儲10個元素。
這是一個很小的數字，所以理論上你可以選擇任何想要的數據（數組，樹，哈希表）。
所以你應該選擇最合適的。
選項包括：

std::map：最少的代碼編寫，各種因素自動
std::vector：空間充分利用，但你應該寫一個查找功能youself
std::hashmap：拍攝出大炮成麻雀。你不需要它提供的99％的功能。這contaner有比你

來源

2016-09-27 04:55:23

10個元素，如外部hashmap的10個可能元素。我正在處理數百萬個散列在10個不同位置的數據，然後內部散列表就是事物變得非常大的地方。但爲什麼我會在10個可能的映射情況下更喜歡unordered_map上的映射？ –

@大衛元請看更新的回答 –

是有道理的。謝謝！ –

unordered_map vs vector +少量元素的自定義散列

回答

相關問題