C ++ stdext hashmap效率 - 重组（？）

Question

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

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

关键元素是无符号整数（uint64），该对象使用此键存储在hashmap中，大小为160 KB。 该程序正在运行，但是当hashmap中的对象数量达到限制时，我必须等待太多。

在此之后，hashmap再次运行良好，正如我所料。我想也许这是一个重组步骤。

但是这些步骤很关键，因为在一定数量的物体之后，这个步骤需要5个小时，而正常的处理步骤大约需要2-3分钟。在此之后，处理变为“正常”。

有没有人遇到过这样的问题？有没有人对这个hashmap有更深入的了解？我没有找到与此主题相关的任何相关内容。

---

我正在尝试将hashmap参数与非默认值一起使用：bucket_size和min_buckets。默认值为bucket_size=4和min_buckets=8。我已经在xhash文件中将它们更改为更大的值，因为我没有设法从代码中更改这些值。我认为min_buckets在我的应用程序中至关重要，我试图“微调”以获得更好的性能，避免重组步骤。

但是我得到另一个问题，一切正常，直到我尝试清除hashmap。这需要很多时间。当我使用它时，默认值运行得非常快。

更改xhash文件是不是一个糟糕的步骤？有没有人之前使用过非默认值？这种缓慢清除的原因是什么？

我的第二个问题与在hashmap中存储指针有关。这个想法很清楚，但我怎么能设法释放尖锐的记忆。我应该创建指向我的对象的指针;这些指针存储在hashmap中，当我需要值时，我可以让它取消引用这个指针。但是我在保存地图后如何清除内存？也许这是一个微不足道的问题，但现在我没有看到解决方案。

感谢您已发布的答案。

Answer 1

复制对象可能非常昂贵（考虑到它的大小）。尝试存储指向对象而不是整个对象的指针，或者如果你想简单地删除，可以使用boost :: shared_ptr。

这样，当数据结构重新组织时，复制速度非常快，因为它只是一个指针赋值，而不是复制巨大对象所需的任何内容。

Answer 2

当容器决定为更多对象分配空间时，听起来就像复制对象的成本一样。最简单的两个选项是：

1. 如果您知道要使用void resize(size_type n)功能插入的对象数量。

2. 您可以在容器中存储指针而不是对象本身。

Answer 3

您的问题是重新分配（和复制）或哈希冲突。

向量受此影响太多（并且指数增加了指数大小）。但是，地图，集合和散列图通常受影响较小。在大多数情况下，后面这些类没有resize（）成员。所以，

• 您可以传递自定义分配器（大多数容器允许AFAIK）
• 选择更好的哈希算法

如果您愿意，可以查看您的hashmap实现，看看它们是否遵循move-idiom。如果他们不试一试。

Answer 4

使用Java。当涉及到有效的哈希映射插入（更好的分配器，没有复制）并在查找上匹配它时，你会惊讶于它击败C ++的顺序。