Python：是否有任何理由*不*缓存对象的散列？

问题描述

我写了一个类，它的 .__ hash __（）实现需要很长时间才能执行。我一直在考虑缓存它的散列，并将它存储在一个像 ._ hash 这样的变量中，这样 .__ hash __（）方法只会返回 ._ hash 。 （可以在 .__ init __（）或第一次 .__ hash __（）的末尾计算）

我的推理是：这个对象是不可变的 - >它的哈希值永远不会改变 - >我可以缓存哈希值。

但现在让我想到：您可以对任何可哈希对象说同样的话。 （除了散列是它们ID的对象外）。

所以有没有理由缓存对象的散列，除了 散列计算速度非常快的小对象？

解决方案

当然，缓存散列值可以。事实上，Python本身就是为字符串做的。权衡是在哈希计算的速度和保存哈希值所花费的空间之间进行的。这种权衡是例如为什么元组不会缓存它们的散列值，但字符串会做（请参阅）。

I've written a class whose .__hash__() implementation takes a long time to execute. I've been thinking to cache its hash, and store it in a variable like ._hash so the .__hash__() method would simply return ._hash. (Which will be computed either at the end of the .__init__() or the first time .__hash__() is called.)

My reasoning was: "This object is immutable -> Its hash will never change -> I can cache the hash."

But now that got me thinking: You can say the same thing about any hashable object. (With the exception of objects whose hash is their id.)

So is there ever a reason not to cache an object's hash, except for small objects whose hash computation is very fast?

解决方案

Sure, it's fine to cache the hash value. In fact, Python does so for strings itself. The trade-off is between the speed of the hash calculation and the space it takes to save the hash value. That trade-off is for example why tuples don't cache their hash value, but strings do (see request for enhancement #1462796).

这篇关于Python：是否有任何理由*不*缓存对象的散列？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！