如何确定是否适合缓存 hashCode() 结果？
假设我有一个不可变的类，其中已编写了 GetHashCode() 函数，我如何知道缓存哈希结果是否有益，或者在大多数情况下这样做是否明智？
考虑到 GetHashCode() 计算的性能已针对基元和字符串值进行了优化，这是否是我应该考虑的事情？
我的一个典型的 GetHashCode() 可能如下所示：
//C#
public override int GetHashCode() {
int hash = 13;
hash = 13 * hash + IntValue;
hash = 13 * hash + (StringValue1 == null ? 0 : StringValue1.GetHashCode());
hash = 13 * hash + (StringValue2 == null ? 0 : StringValue2.GetHashCode());
return hash;
}
我对可能明智的情况的想法是：
- 如果它旨在成为地图或字典的键。
- 如果该映射在其生命周期内会进行多次查找。
Given I have an immutable class of which a GetHashCode() function has been written, how do I know if it would be beneficial to cache the hash result, or in most cases is it even wise to do so?
Considering that the performance of a GetHashCode() calculation has been optimised for primitives and string values, is it even something I should bother considering?
A typical GetHashCode() of mine might look like the following:
//C#
public override int GetHashCode() {
int hash = 13;
hash = 13 * hash + IntValue;
hash = 13 * hash + (StringValue1 == null ? 0 : StringValue1.GetHashCode());
hash = 13 * hash + (StringValue2 == null ? 0 : StringValue2.GetHashCode());
return hash;
}
My thoughts on the matter of situations where it might be wise are:
- If it is intended to be the key of a map or dictionary.
- If the said map will have many lookups within its lifetime.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的观点“1”仅定义何时应该实现
GetHashCode()（以及匹配的Equals） - 在这种情况下，您应该（“2”）期望它是查询中等次数。然而，这里的关键是分析，或者预先存在的场景知识。例如，如果您的散列实际上是对一个大型内部数组进行散列，那么它可能值得缓存。在这种情况下，我会懒惰地缓存它（也许作为int？），除非我知道它将用作密钥（总是），在这种情况下我可能会急切地预先计算它。但在大多数情况下，每次只需按需计算即可。
Your point "1" merely defines when you should implement
GetHashCode()(and a matchingEquals) - and in such scenarios you should ("2") expect it to be queried a moderate number of times. However, the key here is profiling, or a pre-existing knowledge of the scenario. For example, if your hash is actually taking a hash over a large-ish inner array then it is probably worth caching. In such cases, I would cache it lazily (perhaps as anint?) unless I know it is going to be used as a key (always), in which case I might pre-calculate it eagerly.In most cases, though, just calculate it on-demand each time.