c# 中的 _continue_ 关键字计算成本高吗？答案

【问题标题】：Is _continue_ keyword computationally expensive in c#?c# 中的 _continue_ 关键字计算成本高吗？
【发布时间】：2015-03-03 16:02:52
【问题描述】：

当我意识到一个奇怪的行为时，我对我的代码执行了分析。 VS2013 为我的每个 continue 关键字分配 6.5 的百分比！请考虑以下快照。

我在这里漏掉了一点吗？

编辑如果我将continue 替换为if else-if 条件会怎样？下面是另一个配置文件。我可以假设成本消失了，还是只是分散了？！

【问题讨论】：

我怀疑这实际上只是迭代器中对MoveNext 的调用。它本身并不昂贵 - 它只是“跳到循环块的末尾，然后继续下一次迭代”。
尝试用for循环替换你的foreach，看看你是否再次得到相同的数字以继续。 但您必须先通过ToList、ToArray 来迭代您的结果
相比if continue 是更贵。或者是什么问题？
@blam 他可以将第二个两个 if 语句更改为 else if 并删除两个继续。这样，代码在功能上是相同的（当然，还有更多 ContainsKey 检查），但它会显示在分析器中。
如果您担心性能问题，请放弃ContainsKey 检查。例如，Remove 告诉您是否找到并删除了密钥。查找该项目两次是浪费。

标签： c# .net profiling continue

【解决方案1】：

没有； continue 通常映射到无条件分支（br 或 br.s）。这里唯一的“费用”是接下来会发生什么 - 在你的情况下，是MoveNext()。 that 所做的完全取决于您的序列。

【讨论】：

谢谢，我想我最好也花一些时间在迭代上 :) 这似乎包含了为 continue 指定的成本。

【解决方案2】：

我会专注于提高效率
在现实生活中，效率更高会跑得更快

向 cmets 借用
我可能会更快让它在 add
上引发异常而且让它在添加时抛出异常可能不会更快

foreach (var lamda in ...
{
     if (lamda.phi == true)
     {
         ...
     }
     else if (_left.Remove(lamda.Ati))
     {}
     else 
     {
        try 
        {
            _determined.Add(lamda.Ati, lamda.phi)
            _righEnds --; 
        }
        catch (ArgumentException ex)
        {
            // do nothing
        }   
     }
}

关于_determined.Add lamda.phi 总是会是假的
为什么不是 HashSet？
HashSet.Add 返回一个布尔值

【讨论】：

谢谢，我喜欢避免使用第二个 if，因为它消耗了大约 10%，但我仍然不相信第三个 if 替换。我希望有像.TryAdd 这样的东西ConcurrentCollections
HashSet 在这里是比异常更好的选择。
是时候开始使用实际数据进行测试了。那些配置文件％是为了找到热点。 8% 不一定比你的数据快 10%。 8% 可能不会快于 20%。
@BenVoigt 但是如果该字典中有一些 true 值，则 HashSet 不是一个选项。 OP 回来后想要一个 TryAdd for Dictionary。