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

Posted 2023-02-25

【中文标题】c# 中的 _continue_ 关键字计算成本高吗？

【英文标题】：Is _continue_ keyword computationally expensive in c#?

【发布时间】：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 告诉您是否找到并删除了密钥。查找该项目两次是浪费。

【参考方案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。