幾種常見 容器 比較和分析 hashmap, map, vector, list ...hash table

list支持快速的插入和刪除，可是查找費時;

vector支持快速的查找，可是插入費時。

map查找的時間複雜度是對數的，這幾乎是最快的，hash也是對數的。 
若是我本身寫，我也會用二叉檢索樹，它在大部分狀況下能夠保證對數複雜度，最壞狀況是常數複雜度，而std::map在任何狀況下均可以保證對數複雜度，緣由是它保證存諸結構是徹底二叉檢索樹，但這會在存諸上犧牲一些時間。

STL   中的   map   內部是平衡二叉樹，因此平衡二叉樹的性質都具有。查找數據的時間也是對數時間。 vector，在分配內存上通常要比   new   高效的多。

爲何說   hash_map   是對數級的？在不碰撞的狀況下，hash_map是全部數據結構中查找最快的，它是常數級的。 
若是對問題設計了足夠好的hash算法，保證碰撞率很低，hash_map的查找效率不容置疑。 
另外，STL的map，它的查找是對數級的，是除hash_map外最高的了，你能夠說「也許還有改進餘地」，但對於99.9999%的程序員，設計一個比STL   map好的map，我執悲觀態度。 
STL的map有平衡策略（好比紅黑樹什麼的），因此不會退化，不須要考慮數據自己的分佈問題。只不過，若是數據自己是排好序的，用vector或heap會明顯的快些，由於它們的訪問比較簡單。

我想不必懷疑stl::map的查找效率,影響效率最主要的因素是什麼?算法,在查找問題上,有什麼算法比RB_tree更好嗎？至少如今尚未。不否 認你能夠經過本身寫代碼，設計一個符合你須要的BR—TREE，比stl：：map簡捷那麼一點，但最多也就每次迭代中少一行指令而已，處理十萬個數據多 執行十萬行指令，這對你重要嗎？若是你不是在設計OS像LINUX，沒人會關注這十萬行指令花的時間。 
rb-tree的時間花在了插入和刪除上，若是你不是對插入和刪除效率要求很高，你沒有理由不選擇基於rb-tree的stl::map。

大多數程序員寫不出比std::map更好的map，這是固然的。然而並非std::map的全部特性都出如今咱們的程序中，本身編寫的能夠更適合本身的程序，的確會比std::map更快一些。

關於hash_map，它與map的實現機制是不同的，map內部通常用樹來實現，其查找操做是O(logN)的，這個沒有爭議，我就很少說了。 
hash_map的查找，內部是經過一個從key到value的運算函數來實現的，這個函數「只接受key做爲參數」，也就是說，hash_map的查找 算法與數據量無關，因此認爲它是O(1)級的。來這裏的應該都是達人，能夠參看《數據結構》。固然，事實總不這樣完美，再引一段前面我自已說的話，進一步 說明，以避免誤會：

----------------------------------------- 
在不碰撞的狀況下，hash_map是全部數據結構中查找最快的，它是常數級的。 
------------------------------------------ 
注意個人前提：「在不碰撞的狀況下」，其實換句話說，就是要有足夠好的hash函數，它要能使key到value的映射足夠均勻，不然，在最壞的狀況下，它的計算量就退化到O(N)級，變成和鏈表同樣。 
若是說   hash_map   是全部容器中最慢的，也只能說：「最拙劣的hash函數」會使hash_map成爲查找最慢的容器。但這樣說意義不大，由於，最湊巧的排列能使冒泡排序成爲最快的排序算法。

BS: "對於大型容器而言,hash_map可以提供比map快5至10倍的元素查找速度是很常見的,尤爲是在查找速度特別重要的地方.另外一方面,若是hash_map選擇了病態的散列函數,他也可能比map慢得多. "

ANSIC++在1998年以後就沒再有重大改變，而且決定再也不向C++標準庫中作任何重大的變動，正是這個緣由，hash   table(包括hash_map)並無被列入標準之中，雖然它理應在C++標準之中佔有一席之地。 
雖然，如今的大多數編譯平臺支持hash   table，但從可移植性方面考慮，仍是不用hash   table的好。

hehe俺也來湊湊熱鬧。 
1.有的時候vector能夠替代map 
好比key是整數，就能夠以key的跨度做爲長度來定義vector。 
數據規模很大的時候，差別是驚人的。固然，空間浪費每每也驚人。 
2.hash是很難的東西 
沒有高效低碰撞的算法，hash_xxx沒有意義。 
而對不一樣的類型，數據集，不可能有優良的神仙算法。必須因場合而宜。 
俺有的解決方法是GP，可不是飯型，是遺傳編程，收效不錯。

你的百萬級的數據放到vector不大合適。由於vector須要連續的內存空間，顯然在初始化這個容器的時候會花費很大的容量。 
使用map，你想好了要爲其創建一個主鍵嗎？若是沒有這樣的需求，爲何不考慮deque或者list？ 
map默認使用的是deque做爲容器。其實map不是容器，拿它與容器比較意義不大。由於你能夠配置它的底層容器類型。

若是內存不是考慮的問題。用vector比map好。map每插入一個數據，都要排序一次。因此速度反不及先安插全部元素，再進行排序。

用 binary_search對已序區間搜索，若是是隨機存取iterator，則是對數複雜度。可見，在不考慮內存問題的狀況下，vector比map 好。

若是你須要在數據中間進行插入，list 是最好的選擇，vector   的插入效率會讓你痛苦得想死。

涉及到查找的話用map比較好，由於map的內部數據結構用rb-tree實現，而用vector你只能用線性查找，效率很低。

stl還提供了 hash容器，理論上查找是飛快~~~。作有序插入的話vector是噩夢，map則保證確定是按key排序的，list要本身作些事情。

HASH類型的查找確定快，是映射關係嘛，可是插入和刪除卻慢，要作移動操做, LIST類型的使鏈式關係，插入很是快，可是查找卻費時，須要遍歷~~ , 仍是用LIST類型的吧，雖然查找慢點，

先快速排序，而後二分查找，效率也不低