昨天我们通过对散列表极不严谨的介绍，我们大概知道了字典和集合的一些实现方式，今天我们说一下他们这么实现造成的后果，既包括带来的优势，也难免有一些缺点：
Dict？
Dict必须是可散列的：
这几乎是显然的事情——人家内部是散列表实现的嘛，「可散列」具体上可以引申为一下三点：键值可以通过Hash()计算哈希值；可以通过eq()方法检测是否相等【注释1】；同样的键值可以算出相同的Hash值——这三条有点像数学公式，互相都有联系，但是又莫名其妙有一种显然的感觉。
Dict在空间上开销很大：
为了保证Dict在访问时候的速度，内部不仅使用了散列表，而且是非常稀疏的，这样能保证访问时候不会经常需要解决Hash冲突，但是导致Dict在空间上效率非常操蛋，因此，如果你需要存放数量巨大的数据，可以尝试一下使用主要由元组构成的数据结构来储存，否则会造成巨大的空间浪费。
还要值得注意的一点是，如果我们只拿到了一个经过了粗糙打磨的数据对象（甚至是未经处理的原始数据），而计算机的内存又富裕得不得了，那空间优化就不必着急，毕竟，优化和维护性几乎是天然对立的。
键的查询速度非常快
数据结构有一个很重要的研究点就是访问速度跟随数据量级增长造成的影响，Dict提供了一种对数据量大小很不敏感的访问速度，把字典的大小从1000扩大10000倍，时间消耗不到原来的三倍。
键的次序和元素的添加次序有关系
无论是何种冲突解决方案，散列表可能造成冲突的元素所放置的位置总和被添加进字典的次序有关，虽然桶式解决方案可能稍微好一点，但我们仍然要知道，添加有冲突的键，顺序总是不一样的。
Set？
由于内部的散列表的巨大相似性，Set和Dict有很多相似之处，我们简单写：
集合元素必须可散列
集合在空间上效率不高
元素次序和添加次序有关
判断元素是否属于Set的速度非常快
我们经常需要执行a∈Set这种操作，由于散列表的神优化，集合中或者这样的判断速度非常快。
网友评论