Try / Catch比哈希查询便宜吗？ [英] Is Try/Catch ever LESS expensive than a hash lookup?

问题描述

我知道异常捕获可能会很昂贵，但是我想知道是否在某些情况下它实际上比查找便宜呢？

I'm aware that exception trapping can be expensive, but I'm wondering if there are cases when it's actually less expensive than a lookup?

例如，如果我有一本大字典，我可以测试一个键是否存在：

For example, if I have a large dictionary, I could either test for the existence of a key:

If MyDictionary.ContainsKey(MyKey) Then _
  MyValue = MyDictionary(MyKey) ' This is 2 lookups just to get the value.

或者，我可以捕获一个例外：

Or, I could catch an exception:

Try
  MyValue = MyDictionary(MyKey) ' Only doing 1 lookup now.
Catch(e As Exception)
  ' Didn't find it.
End Try

异常捕获是否总是比上述查找昂贵，还是

Is exception trapping always more expensive than lookups like the above, or is it less so in some circumstances?

推荐答案

与字典查找有关的事情是它们在恒定或接近恒定的时间内发生。字典中包含一项还是一百万项，花费的计算机时间大致相同。之所以提出这一点，是因为您担心要在大型词典中进行两次查找，而事实是，与在小型词典中进行两次查找并没有太大区别。附带说明一下，这里的含义之一是，字典并不总是小型集合的最佳选择，尽管我通常会发现，对于那些小型集合而言，额外的清晰度仍然胜过任何性能问题。

The thing about dictionary lookups is that they happen in constant or near-constant time. It takes your computer about the same amount of time whether your dictionary holds one item or one million items. I bring this up because you're worried about making two lookups in a large dictionary, and reality is that it's not much different from making two lookups in a small dictionary. As a side note, one of the implications here is that dictionaries are not always the best choice for small collections, though I normally find the extra clarity still outweighs any performance issues for those small collections.

确定字典可以进行查找的速度的一件事是生成 哈希 值，用于特定对象。有些对象可以比其他对象快得多。这意味着答案取决于字典中对象的类型。因此，唯一可以确定的方法是构建一个版本，对每个方法进行数十万次测试，以找出可以更快完成该方法的集合。

One of the things that determines just how fast a dictionary can make it's lookups is how long it takes to generate a hash value for a particular object. Some objects can do this much faster than others. That means the answer here depends on the kind of object in your dictionary. Therefore, the only way to know for sure is to build a version that tests each method a few hundred thousand times to find out which completes the set faster.

这里要记住的另一个因素是，主要是Catch块的异常处理速度很慢，因此您需要寻找正确的组合查找命中和未命中与您在生产中期望的合理匹配。因此，您无法在此处找到一般性准则，或者如果这样做可能是错误的。如果您只是很少有遗漏，那么我希望异常处理程序做得更好（并且由于遗漏在某种程度上是个例外，所以它也是 right 解决方案） 。如果您想念的次数更多，我可能更喜欢采用其他方法

Another factor to keep in mind here is that it's mainly just the Catch block that is slow with exception handling, and so you'll want to look for the right combination of lookup hits and misses that reasonably matches what you'd expect in production. For this reason, you can't find a general guideline here, or if you do it's likely to be wrong. If you only rarely have a miss, then I would expect the exception handler to do much better (and, by virtue of the a miss being somewhat, well, exceptional, it would also be the right solution). If you miss more often, I might prefer a different approach

在我们这样做的时候，请不要忘记 Dictionary.TryGetValue（）

And while we're at it, let's not forget about Dictionary.TryGetValue()

这篇关于Try / Catch比哈希查询便宜吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！