快速容器，实现一致的性能

Fast container for consistent performance

本文关键字：性能实现更新时间：2023-10-16

我正在寻找一个容器来支持频繁的添加/删除。我不知道集装箱可能会增长到多大，但我不想因为大规模的重新分配而导致摊位。我需要在性能和一致的行为之间取得良好的平衡。

最初，我考虑了std::tr1::unordered_map，但由于我不知道数据集的上界，因此碰撞确实会降低unordered_map的性能。这不是一个好的哈希函数的问题，因为无论它有多好，如果map的占用超过桶数的一半，碰撞很可能会成为一个问题。

现在我考虑std::map，因为它没有碰撞的问题，但它只有log(n)的性能。

当你不知道unordered_map的目标大小时，是否有一种方法可以智能地处理冲突?对于处理这种情况，我想还有其他的办法吗?

谢谢

这是一个运行时容器，对吗?

您是在末尾添加(如push_back)还是在前面或中间添加?你是在随机地点搬走吗?

你如何引用其中的信息?随机的，或者从前面或后面，还是什么?

如果你需要随机访问，基于数组或哈希的东西是首选。

如果重新分配是一个大问题，你想要更像树或列表的东西。

即便如此，如果您不断地对放入容器中的对象进行new -ing(和delete -ing)，仅这一点就可能消耗大量时间，在这种情况下，您可能会发现将使用过的对象保存在垃圾列表中是有意义的，这样您就可以回收它们。

我的建议是，与其纠结于容器的选择，不如选择一个，编写程序，然后对其进行调优，就像本例中所示。无论你选择什么，你都可能想要改变它，也许不止一次。我在这个例子中发现，任何已经存在的容器类都是通过编程的方便性来证明其存在的，而不是通过最快的速度。

我知道这违反直觉，但是除非程序中的一些其他活动最终成为主要成本，并且您无法缩小它，否则您最终的速度爆发将需要手动编码数据结构。

您需要什么样的访问权限?顺序，随机访问，按键查找?另外，您可以手动重新散列无序映射(rehash方法)，并设置其负载因子。在任何情况下，当链变得太长时(即，当超过负载因子时)，哈希都会自行重建。此外，哈希表的减速点是当它满了80%，而不是50%。

你真的应该阅读文档，例如这里