我认为这个问题已经部分回答了，因为没有提供关于以“int”类型作为键的性能的信息。我做了我自己的分析，我发现std::map在许多实际情况下使用整数作为键时可以胜过std::unordered_map(在速度上)。

整数测试

测试场景包括使用顺序键和随机键填充映射，以及长度为17的倍数[17:119]的字符串值。执行测试时，元素计数范围为[10:10000000]，以10为幂。

Labels:

Map64: std::map<uint64_t,std::string>
Map32: std::map<uint32_t,std::string>
uMap64: std::unordered_map<uint64_t,std::string>
uMap32: std::unordered_map<uint32_t,std::string>

插入

Labels:

Sequencial Key Insert: maps were constructed with keys in the range [0-ElementCount]
Random Key Insert: maps were constructed with random keys in the full range of the type

关于插入的结论:

当映射大小小于10000个元素时，在std::map中插入展开键往往优于std::unordered_map。 在std::map中插入密集键在1000个元素下与std::unordered_map没有性能差异。 在所有其他情况下，std::unordered_map往往执行得更快。

查找

Labels:

Sequential Key - Seq. Search: Search is performed in the dense map (keys are sequential). All searched keys exists in the map.
Random Key - Rand. Search: Search is performed in the sparse map (keys are random). All searched keys exists in the map.

(label names can be miss leading, sorry about that)

关于查阅的结论:

当地图大小小于1000000个元素时，在std::map上的搜索往往略优于std::unordered_map。 密集std::map的搜索性能优于std::unordered_map

查询失败

Labels:

Sequential Key - Rand. Search: Search is performed in the dense map. Most keys do not exists in the map.
Random Key - Seq. Search: Search is performed in the sparse map. Most keys do not exists in the map.

(label names can be miss leading, sorry about that)

关于查找失败的结论:

在std::map中搜索缺失是一个很大的影响。

一般的结论

即使在需要速度时，std::map用于整数键在许多情况下仍然是更好的选择。举个实际的例子，我有一本字典 在这里查找从未失败，尽管键具有稀疏分布，但它将在与std::unordered_map相同的速度下执行得更差，因为我的元素计数低于1K。内存占用显著降低。

字符串的测试

为了供参考，我在这里给出了字符串[string]映射的计时。键字符串是由一个随机的uint64_t值形成的，值字符串是在其他测试中使用的相同。

Labels:

MapString: std::map<std::string,std::string>
uMapString: std::unordered_map<std::string,std::string>

评价平台

操作系统:Linux - OpenSuse风滚草

编译器:g++ (SUSE Linux) 11.2.1 20210816

CPU: Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz

内存:64 gb

通过使用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.

性能

下面两张图不言自明:

我只是想指出……有很多种unordered_map。

在哈希图上查找维基百科文章。根据所使用的实现的不同，查找、插入和删除方面的特征可能有很大差异。

这是我最担心的添加unordered_map到STL:他们将不得不选择一个特定的实现，因为我怀疑他们会走政策的道路，所以我们将被困在一个实现的平均使用，而没有其他情况…

例如，一些哈希映射具有线性重新哈希，其中不是一次重新哈希整个哈希映射，而是在每次插入时重新哈希一部分，这有助于分摊成本。

另一个例子:一些哈希映射使用一个简单的节点列表作为bucket，其他使用map，其他不使用节点，但找到最近的槽，最后一些将使用节点列表，但重新排序，以便最后访问的元素位于前面(像缓存一样)。

因此，目前我倾向于std::map或loki::AssocVector(用于冻结数据集)。

不要误解我的意思，我希望使用std::unordered_map，将来也可能会使用，但是当您想到实现它的所有方法和由此产生的各种性能时，很难“信任”这样一个容器的可移植性。

I was intrigued by the answer from @Jerry Coffin, which suggested that the ordered map would exhibit performance increases on long strings, after some experimentation (which can be downloaded from pastebin), I've found that this seems to hold true only for collections of random strings, when the map is initialised with a sorted dictionary (which contain words with considerable amounts of prefix-overlap), this rule breaks down, presumably because of the increased tree depth necessary to retrieve value. The results are shown below, the 1st number column is insert time, 2nd is fetch time.

g++ -g -O3 --std=c++0x   -c -o stdtests.o stdtests.cpp
g++ -o stdtests stdtests.o
gmurphy@interloper:HashTests$ ./stdtests
# 1st number column is insert time, 2nd is fetch time
 ** Integer Keys ** 
 unordered:      137      15
   ordered:      168      81
 ** Random String Keys ** 
 unordered:       55      50
   ordered:       33      31
 ** Real Words Keys ** 
 unordered:      278      76
   ordered:      516     298

如果你用Visual Studio 2010编译项目-忘记字符串的unordered_map。 如果你使用更现代的Studio，比如2017 -那么unordered_map比ordered map快得多。