最有效的关联容器与std :: string作为关键？

Question

我已经读过某个地方std :: map，在当前的编译器中，仍然是我们在STL中最有效的关联容器，即使是std :: unsorted_map - 从我在某处读到的，我不是确定where--只有当有很多条目时才会在find（）上变得更有效率，例如超过40k。

所以现在我不再确定了，因为我总是假设哈希映射更有效率，至少在字符串键的情况下。

简而言之：

如果我必须选择未知条目数且 std :: string作为键的关联容器，那么（至少在理论上）找到更有效（速度）的选择？

Answer 1

个人资料，个人资料，个人资料......

字符串作为键的问题是比较它们非常慢（想想1000个字符的字符串的最后一个字符的差异）。带有字符串键的unordered_map的优点至少部分来自于必须仅比较固定宽度散列值的事实，因此实际上无序映射可能是快得多。

例如，散列实现可以选择仅使用固定数量的展开数字来计算散列值，从而最终在同一个桶中放置一些接近相同的字符串，因此这是一种权衡。您可以编写一组两个容器执行效果非常差的键值，但对于“随机”或“典型”字符串集合，我的赌注是在哈希容器上。

Answer 2

如果您有40k或更多条目，则不应将字符串（或元素列表等）用作标准容器中的关联键。相反，在更早的时候，特里树或三元树成为更好的选择。这两者都可以构建关联结构，只比较字符串的每个字符（或列表的元素等）一次。有序地图在每个节点进行比较（因此是O（m log n） - m大小的字符串，n个元素），无序地图在这些大小上遭受更多的碰撞。

三元树（每个子树在单个字符比较中分支到较少，相等或更大的字符）对较好的实现的记忆最少，但尝试到目前为止最快。这两个都可以从boost.graph或其他一些通用图库构建。