几种常见 容器 比较和分析 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类型的吧，虽然查找慢点，

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