我最近做了一个测试，做了50000个归并排序。这意味着如果字符串键是相同的，合并字节字符串。最终的输出应该是排序的。这包括查找每一个插入。

对于地图实现，完成这项工作需要200毫秒。对于unordered_map + map，插入unordered_map需要70 ms，插入map需要80 ms。所以混合实现快了50毫秒。

我们在使用地图之前应该三思。如果您只需要在程序的最终结果中对数据进行排序，那么混合解决方案可能会更好。

通过使用std::unordered_map，您可以声明在代码中任何地方都不依赖于被排序的映射。在某些情况下，这些附加的上下文信息可能有助于理解这个映射在程序中是如何实际使用的。随着性能作为一个副作用的到来，清晰度可能更加重要。

当然，当您需要使用有序映射时，没有编译器会阻止您使用无序映射，但这不大可能工作得很好，因此读者可能会认为这不是一个错误。

总结

假设顺序不重要:

如果你打算一次构建一个大的表，并做很多查询，使用std::unordered_map 如果你要构建一个小的表(可能少于100个元素)并进行大量的查询，请使用std::map。这是因为它的读数是O(log n) 如果你要改变表很多，那么std::map可能是一个不错的选择。 如果你有疑问，请使用std::unordered_map。

历史背景

在大多数语言中，无序映射(又名基于哈希的字典)是默认映射，但在c++中，你得到的是有序映射作为默认映射。这是怎么发生的?有些人错误地认为c++委员会用他们独特的智慧做出了这个决定，但不幸的是，事实比这更丑陋。

It is widely believed that C++ ended up with ordered map as default because there are not too many parameters on how they can be implemented. On the other hand, hash based implementations has tons of things to talk about. So to avoid gridlocks in standardization they just got along with ordered map. Around 2005, many languages already had good implementations of hash based implementation and so it was more easier for the committee to accept new std::unordered_map. In a perfect world, std::map would have been unordered and we would have std::ordered_map as separate type.

性能

下面两张图不言自明:

不要忘记map保持其元素的顺序。如果你不能放弃它，显然你不能使用unordered_map。

另外需要记住的一点是，unordered_map通常会使用更多的内存。Map只有一些内部指针和每个对象的内存。相反，unordered_map有一个大数组(在某些实现中会变得相当大)，然后为每个对象提供额外的内存。如果需要内存感知，map应该会更好，因为它缺少大数组。

所以，如果你需要纯粹的查找-检索，我认为unordered_map是最好的方法。但总会有权衡，如果你负担不起，那你就不能使用它。

仅凭个人经验，我发现在主实体查找表中使用unordered_map而不是map时，性能有了巨大的改进(当然是度量的)。

另一方面，我发现它在重复插入和删除元素时要慢得多。它非常适合相对静态的元素集合，但如果您正在进行大量的插入和删除，那么哈希+桶似乎就会累加起来。(注意，这需要经过多次迭代。)

这里没有真正充分提到的显著差异:

map keeps iterators to all elements stable, in C++17 you can even move elements from one map to the other without invalidating iterators to them (and if properly implemented without any potential allocation). map timings for single operations are typically more consistent since they never need large allocations. unordered_map using std::hash as implemented in the libstdc++ is vulnerable to DoS if fed with untrusted input (it uses MurmurHash2 with a constant seed - not that seeding would really help, see https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/). Being ordered enables efficient range searches, e.g. iterate over all elements with key ≥ 42.

哈希表具有比普通map实现更高的常量，这对于小型容器非常重要。最大尺寸是10个，100个，甚至1000个或更多?常数和以前一样，但是O(log n)接近O(k)。(记住，对数复杂度仍然很好。)

一个好的哈希函数取决于你的数据的特征;所以如果我不打算看一个自定义哈希函数(但肯定可以改变我的想法，而且很容易，因为我typedef几乎所有的东西)，即使默认选择执行体面的许多数据源，我发现map的有序性质是足够的帮助，最初我仍然默认映射而不是哈希表在这种情况下。

另外，这样您甚至不必考虑为其他类型(通常是UDT)编写哈希函数，只需编写op<(无论如何您都想要)。