Question

我考虑使用Dictionary<string, object>按字符串键查找值。根据我的知识，密钥越长，在字典中进行查找所需的时间越长。我的密钥可能很长，比如/page-1/page-2/page-3/page-4 ......等等，每个名字都可以由他们自己很长。

在词典中使用长字符串键时，我可以期待什么性能？什么机制导致这些成本？

Answer 1

每次访问该字典中的键时，必须对传入的输入进行哈希处理。 .NET不会缓存字符串哈希码。散列是输入字符串长度中的线性运算。 10倍的长度约为散列成本的10倍。

平等比较也是如此。当字典发现两个哈希码是等于的（这发生在每次成功的查找和每次键冲突时），它必须比较字符串。这又是一个线性操作，但速度非常快。

这几乎是长按键造成的唯一成本。

我无法告诉您这是否足够快或不适合您的使用案例。你必须要衡量。答案取决于密钥长度以及访问字典的频率。

Answer 2

这就是为字符串计算HashCode的方法。

public override unsafe int GetHashCode()
{
  if (HashHelpers.s_UseRandomizedStringHashing)
    return string.InternalMarvin32HashString(this, this.Length, 0L);
  fixed (char* chPtr = this)
  {
    int num1 = 352654597;
    int num2 = num1;
    int* numPtr = (int*) chPtr;
    int length = this.Length;
    while (length > 2)
    {
      num1 = (num1 << 5) + num1 + (num1 >> 27) ^ *numPtr;
      num2 = (num2 << 5) + num2 + (num2 >> 27) ^ numPtr[1];
      numPtr += 2;
      length -= 4;
    }
    if (length > 0)
      num1 = (num1 << 5) + num1 + (num1 >> 27) ^ *numPtr;
    return num1 + num2 * 1566083941;
  }
}

因此我们可以看到哈希码计算成本直接取决于字符串的长度。

字典中的长字符串键会导致性能问题吗？

2 个答案: