大型条目的慢 std::map答案

【问题标题】：slow std::map for large entries大型条目的慢 std::map
【发布时间】：2019-05-11 08:17:32
【问题描述】：

我们有 48,16,703 个这种格式的条目。

1 abc
2 def
...
...
4816702 blah
4816703 blah_blah

由于条目的数量很大，我担心 std::map 在插入过程中会花费很多时间，因为它还需要为每次插入进行平衡。

仅将这些条目插入地图需要很长时间。我在做

map[first] = second;

两个问题： 1.我在这些情况下使用 std::map 是否正确？ 2.我按上述方式插入是否正确。或者我应该使用 map.insert()

我很抱歉没有做实验并写出绝对数字，但我们希望就我们做对与否的事情达成普遍共识。

此外，它们的键并不总是连续的..

附：当然，稍后我们还需要访问该映射以获取与键对应的值。

【问题讨论】：

如果键只是一个连续的整数序列，你可以使用数组或向量
@Tharwen，感谢您的快速回答，但它们不是连续的。那是不好的部分。编辑了问题。
如果不是，std::unordered_map 应该更合适，因为它的插入平均时间复杂度是恒定的。
即使数字不连续，但有很多条目，例如超过最大索引的一半，并且您更关心速度而不是大小，使用具有 o(1) 插入和检索的数组或向量可能仍然更有意义。
如果您的键序列已经排序，请尝试map.insert(map.end(), {first, second})。 Demo。即使他们大部分是连续的，这将是一场胜利。

标签： c++ performance hashmap

【解决方案1】：

如果之后不需要插入到map中，可以构造一个未排序的数据向量，根据key排序，然后使用std::equal_range等函数进行搜索。
它与std::map 的复杂性相同，但分配要少得多。

【讨论】：

【解决方案2】：

使用std::unordered_map，其插入时间复杂度比std::map 好得多，正如参考文献所述：

Complexity

Single element insertions:
    Average case: constant.
    Worst case: linear in container size.

Multiple elements insertion:
    Average case: linear in the number of elements inserted.
    Worst case: N*(size+1): number of elements inserted times the container size plus one.

May trigger a rehash (not included in the complexity above).

这比std::map插入的对数时间复杂度要好。

注意：std::map 的插入可以享受“amortized 常数，如果给出提示并且给出的位置是最优的。”。如果您是这种情况，请使用地图（如果矢量不适用）。

@n.m.提供了一个代表Live demo

【讨论】：

除非他们继续重新散列。
另一个相当大的优势可能是较低的内存开销。例如，在 libstdc++ 中，std::map 被实现为红黑树。每个存储的元素都有 32 字节的内存开销（64 位拱 - 左/右/父节点指针和颜色标志）。对于哈希表，可能会使用一两个指针。
是的，Matthieu，这就是 OP 应该进行基准测试的原因，因为对于他的应用程序来说，这可能是一个问题，但我认为不会。 @DanielLangr 确实，虽然我找不到 any support，但这就是为什么我没有将它包括在我的答案中。
@gsamaras 当然，这是定义的实现。任何人都可以探索 libstdc++ 或 libc++ 的源代码或微软的实现以了解更多细节。
@n.m.我也在考虑这个...更新我的答案，谢谢！我借了你的demo，希望你不要介意。 :)