【问题标题】:Hashtable slow to add values?哈希表添加值很慢?
【发布时间】:2010-11-25 14:38:10
【问题描述】:

我目前正在使用哈希表来存储唯一标识符和关联数据的列表,所有这些都是从文件中读取的。

这个数据文件的长度可以很大,从1个条目到几十万个。我注意到一旦超过大约 50,000 个条目,向 Hashtable 添加条目的速度会显着减慢。

我认为设置初始容量可能会有所帮助,但显然我不知道这个数字,因为数据是从文件中读取的。谁能建议一种加快添加大量条目的方法,或者这种行为很正常吗?

编辑:现在我只使用哈希表。我认为它可能应该是 Dictionary,但这似乎是一个单独的问题。

【问题讨论】:

  • 你用的是什么类?字典?
  • 你有没有测试过设置大容量是否会在有很多要插入的项目时提高性能?
  • 设置容量应该没有太大影响 - 当您不知道您将拥有多少条目时不应该这样做(例如 1 到 100.000+ 之间的任何内容)。
  • 我没有测试过,但我同意 tanascius - 如果我只有
  • 在将文件插入字典之前,您是否将文件读入内存?请这样做(出于测试目的),以确保插入确实是问题所在。

标签: c# collections hashtable


【解决方案1】:

See here 用于比较大量项目的哈希表和字典。

【讨论】:

  • 我没想到差别会如此之大 - 看起来切换到字典对解决我的问题大有帮助。但是,我现在无法测试,但我怀疑我会在使用 Dictionary 时看到同样的减速。
  • 这个比较仍然很有趣,因为它使用 10,000,000 个键和一个 GUI 作为 id 进行测试。大约需要 6 秒。所以 50,000 个条目应该没有瓶颈......这就是为什么我认为它可能是文件而不是插入......
  • 这个基准测试不是很好,因为新的 GUID 是在定时循环内生成的,并且与哈希表访问相比,GUID 的生成速度很慢。在快速测试中,我发现创建新 GUID 所需的时间大约是插入 Dictionary 的 6 倍。
  • 好的,这是一个问题——但不是在这种情况下。在 6 秒内插入 10,000,000 个条目。在时间测量期间创建额外的 GUID 速度很快,不会导致瓶颈。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-07-21
  • 2015-04-28
  • 2016-03-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多