google::dense_hash_map vs boost::unordered_map 性能问题答案

【问题标题】：google::dense_hash_map vs boost::unordered_map performance issuegoogle::dense_hash_map vs boost::unordered_map 性能问题
【发布时间】：2016-04-09 12:00:18
【问题描述】：

我最近一直在尝试提高软件的性能，该软件花费 60% 的时间在 hashmap 中进行搜索（通过 valgrind profiler 确认）。

当前实现使用boost::unordered_map<long long, FrequencyKey>。我想将它与google::dense_hash_map<long long, FrequencyKey> 进行比较。我在代码中更改了一行

boost::unordered_map<long long, FrequencyKey> result;

到

google::dense_hash_map<long long, FrequencyKey> result;
result.set_empty_key(-1);

地图接口在两个地方被调用。在大循环之前result.clear()。在循环内result[key]。

使用boost::unordered_map<long long, FrequencyKey> 我的软件性能是118 req/s。通过上面列出的更改，我得到 0.5 req/s。

我显然做错了什么，但在浏览了文档和 github code 之后我自己无法弄清楚。

我正在使用 gcc/g++ 4.4.7 在 CentOS 6.5 上编译代码。

【问题讨论】：

在检查 hash-map 的性能时，第一步是检查发生的冲突。使用std::unordered_map 和类似接口，您可以遍历存储桶列表并计算项目数，每次存储桶包含 N > 1 个项目时，您就会有 (N-1) 次碰撞，这会减慢您的速度。除此之外...不幸的是，您的问题缺少代码：产生MCVE 或遭受无用的（对您而言）答案：x

标签： c++ performance boost hashmap

【解决方案1】：

我不认为你做错了什么。 dense_hash_map 针对内存而非速度进行了优化。

我怀疑你的哈希函数真的很慢，或者数据对于哈希映射不是很好。

如果 hash_map 中的值很少（例如

如果您有自定义哈希函数，请尝试为其编写基准测试。如果在二进制文件中内联，Valgring 可能会跳过它。

此外，如果您可以为条目分配连续的 ID，则可以跳过地图，只需使用向量来存储数据。并非总是可行，但它总是比 hash_map 快。

最后，result[key] 应该插入具有默认值的键。值的构造函数可能是问题的根源，也可能是副本（如果有的话）。同样，这可能会被内联为二进制文件中的优化，因此您不能保证在 Valgrind 中看到它。如果您没想到会发生插入，这也可能会使地图膨胀到足以造成性能问题。

【讨论】：

感谢您的输入@Sorin，但恐怕您的 cmets 都不适用于我的情况。我平均存储 500k 个条目，不超过 1.5M。密钥很长，带有哈希 fn std::tr1::hash<long long>。根据文档，dense_hash_map 针对速度进行了优化，sparse_hash_map 针对内存进行了优化。构造函数对于映射值并不重，我尝试过对象池但没有更好的性能。最后，operator[] 插入默认值的行为（当 key 不存在于 map 中时）是故意使用的，boost::unordered_map 的工作原理完全相同。
@MaciejDonajski 抱歉，这些建议都不起作用。请再次检查文档，我们中的一个人弄错了。如果 hash_map 是稀疏的，它会使用更多的内存（它是稀疏的，因为使用的条目在两者之间很远）。我可能错了，但可能值得仔细检查。
我有同样的直觉，但来自 github repo 自述文件的确切引用是 sparse_hash_map has memory overhead of about 2 bits per hash-map entry, dense_hash_map has a factor of 2-3 memory overhead: if your hashtable data takes X bytes, dense_hash_map will use 3X-4X memory total. 和 sparse_hash_map uses very little space overhead, 1-2 bits per entry. dense_hash_map is very fast, particulary on lookup.。但无论如何我都会尝试:)。
恰恰相反，google::dense_hash_map 针对速度进行了优化。