【问题标题】:Bucket count in unordered_mapunordered_map 中的桶数
【发布时间】:2017-07-20 07:17:18
【问题描述】:

在下面给出的示例程序中(来源:http://www.cplusplus.com/reference/unordered_map/unordered_map/rehash/

// unordered_map::rehash
#include <iostream>
#include <string>
#include <unordered_map>

int main ()
{
  std::unordered_map<std::string,std::string> mymap;

  mymap.rehash(20);

  mymap["house"] = "maison";
  mymap["apple"] = "pomme";
  mymap["tree"] = "arbre";
  mymap["book"] = "livre";
  mymap["door"] = "porte";
  mymap["grapefruit"] = "pamplemousse";

  std::cout << "current bucket_count: " << mymap.bucket_count() << std::endl;

  return 0;
}

输出变成:

current bucket_count: 23

为什么桶数变成 23? 对堆大小有什么影响?堆分配什么时候完成?在存储桶重新散列或实际插入时?动态释放何时完成?何时使用clear()erase() 或两者兼而有之?

【问题讨论】:

  • 如果您提出一个问题并寻找该问题的答案,则此网站效果最佳。您在这里有大约 6 个问题。

标签: c++ heap-memory unordered-map dynamic-allocation g++4.9


【解决方案1】:

libstdc++ 使用的默认 rehash 策略是上升到大于或等于请求数量的桶的最小素数。 23 是 20 以上的最小素数。

【讨论】:

  • 对heapsize有什么影响?堆分配什么时候完成?在存储桶重新散列或实际插入时?动态释放何时完成?何时使用 clear() 或 erase() 或两者兼而有之?
  • @Dr.DebasishJana 不要使用评论提出 5 个问题,请发布 5 个新问题。评论只能用于要求澄清。
【解决方案2】:

哈希表的大小通常比要存储在表中的项目数“舒适地”大。这是因为两个不同的项目映射到同一个桶的概率随着哈希表的填充而增加。

如下图来自 wikipedia (image source) 所示,对于某些解决冲突的方法,如果哈希表的“负载因子”---使用的桶的百分比---超过一定的分数。

因此,桶的数量应始终大于哈希表中的元素数量。

将桶的数量设为素数有助于确保哈希表中的条目在其中均匀分布。一般来说,任何与桶数共享一个公因子的键都将被散列到一个是这个因子的倍数的桶中。因此,如果您将桶数设置为 20,并且您的哈希值恰好是偶数,您将浪费大约 50% 的表空间。如果您的密钥有 4、5 或 10 等因数,情况会更糟。

了解上述内容后,您可以了解为什么哈希表可能比您指定的要大:额外的空间(通常)有助于提高性能。您还可以看到为什么垃圾箱的数量是质数:因为这样可以更好地利用您拥有的空间。将这些结合起来,23 似乎是一个合理的选择。

【讨论】:

    猜你喜欢
    • 2021-07-29
    • 1970-01-01
    • 1970-01-01
    • 2011-08-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多