C++ stdext hashmap效率-重组(?)

Question

我遇到了一件与stdext hashmap相关的非常奇怪的事情。我必须处理很多对象，快速访问元素是一个优先事项。我的程序从一个文件中读取对象值，如果它是一个新元素，那么将这个值插入到一个hashmap中，如果它是一个已经处理过的对象，那么在hashmap中更改存储的值。

我的问题与hashmap(stdext)有关。我还没有找到这个容器的任何初始化选项。

key元素是一个无符号整数(uint64)，该对象以该键存储在哈希映射中，大小为160 KBytes。

该程序正在工作，但当hashmap中的对象数量达到极限时，我不得不等待太多。

在此之后，hashmap又开始正常工作了，正如我所期望的。我想也许这是一个重组的步骤。

但是这些步骤是非常关键的，因为经过一定数量的对象之后，这个步骤需要5个小时才能完成，而一个正常的处理步骤大约需要2-3分钟。在此之后，处理就变得“正常”了。

有人遇到过这样的问题吗？有没有人对这个hashmap有更深的了解？我还没有找到与这个话题相关的任何东西。

我正在尝试使用具有非默认值的hashmap参数：bucket_size和min_buckets。它的默认值是bucket_size=4和min_buckets=8。我在x散列文件中将它们更改为更大的值，因为我没有设法从代码中更改这些值。我认为min_buckets在我的应用程序中是至关重要的，我试图“细化”以获得更好的性能，避免重新组织步骤。

但是我遇到了另一个问题，在我试图清除hashmap之前，一切都很好。这需要很长时间。当我将它与默认值一起使用时，运行速度非常快。

更改x散列文件是一个糟糕的步骤吗？以前有人用过非默认值吗？是什么原因造成这种缓慢的清晰？

我的第二个问题与在hashmap中存储指针有关。这个想法是明确的，但我如何才能设法释放尖刻的记忆。我应该创建指向我的对象的指针；这些指针存储在hashmap中，当我需要这个值时，我可以让它去引用这个指针。但是，在我保存了地图之后，我怎么才能清除记忆呢？也许这是一个琐碎的问题，但现在我看不到解决办法。

谢谢你已经发布的答案。

Answer 1

复制您的对象可能非常昂贵(考虑到它的大小)。尝试存储指向对象的指针，而不是存储整个对象，如果要使删除变得简单，则尝试存储boost::shared_ptr。

这样，当数据结构自我组织时，复制非常快，因为它只是一个指针赋值，而不是复制巨大对象所需的任何东西。

Answer 2

听起来，当容器决定为更多的对象分配空间时，您会受到复制对象成本的影响。最简单的两个选择是：

如果您知道要使用.

1. 函数插入的对象数量，则可以在容器中而不是对象本身中存储指针。

Answer 3

使用Java。当涉及到高效的哈希映射插入(更好的分配程序，而不是复制)时，您会对其优于C++的顺序感到震惊，并在查找时匹配它。