性能：总是分配布尔值还是先检查值？答案

【问题标题】：Performance: assign boolean value always or check value first?性能：总是分配布尔值还是先检查值？
【发布时间】：2011-06-02 23:24:22
【问题描述】：

我确定它可以忽略不计，但考虑到我想从方法中将 true 分配给布尔字段，这个选择有什么不同吗？如果有，为什么？

field = true; // could already be true, but I don't care

对

if(!field) field = true;

【问题讨论】：

我同意你的观点，我敢肯定它可以忽略不计！说真的，一个更有趣的问题是哪个更清晰，更容易维护。
至于您的实际问题，版本中带有 if 的两条不同路径将花费不同的时间，因此您在不知道每条路径发生的概率的情况下无法真正回答。也就是说，我很难相信简单的无条件分配会被击败。
如果我有这样的问题，在这种情况下我会使用第一个关心性能的人，这是你的约定。

标签： c# .net vb.net boolean

【解决方案1】：

我会说不。但这确实取决于我们真正谈论的是 field 而不是 property，这可能（尽管它绝对不应该) 在您包含的两个 sn-ps 中表现出不同的行为（即，如果在 getter 中存在具有副作用的逻辑）。

更新：如果您谈论的是性能开销，实际上并没有什么区别——但是我相信分配的开销要小得多（比阅读价值）。下面是一个示例程序来演示这一点：

bool b = false;

Stopwatch sw = Stopwatch.StartNew();
for (int i = 0; i < int.MaxValue; ++i)
{
    b = true;
}
sw.Stop();

TimeSpan setNoCheckTime = sw.Elapsed;

sw = Stopwatch.StartNew();
for (int i = 0; i < int.MaxValue; ++i)
{
    // This part will never assign, as b will always be true.
    if (!b)
    {
        b = true;
    }
}
sw.Stop();

TimeSpan checkSetTime = sw.Elapsed;

Console.WriteLine("Assignment: {0} ms", setNoCheckTime.TotalMilliseconds);
Console.WriteLine("Read: {0} ms", checkSetTime.TotalMilliseconds);

我的机器上的输出：

分配：2749.6285 毫秒读取：4543.0343 毫秒

【讨论】：

对，我只是在询问字段——赋值或值检查是否有更大的开销？房地产完全是另一回事。 Setter 也很容易产生开销，例如将 value 与字段进行比较、引发属性更改通知等。
@Jay：好的，我认为“差异”是指不同的行为。如果我们谈论的是开销，分配似乎（根据我自己的测试）具有稍微更少的开销。我将添加一个示例程序。
@Jay 你不是在比较赋值和值检查：你是在比较赋值和值检查，可能是赋值。
我真的怀疑内存写入比读取快/慢。请注意，与仅进行单次写入的第一个测试相比，您的第二种情况（不写入）进行比较和分支。
@David：你说得对，但如果 Jay 真的想要比较的是赋值和值检查，那么上面的示例程序实际上就是这样做的。

【解决方案2】：

对于一个字段，只需设置它。对于属性，它可能更复杂，这取决于 get 或 set 是否过于昂贵，和/或 set 是否在内部检查（绕过事件等）。

作为属性的一般规则，只需设置它，直到您知道这是由于分析导致的问题。

对于字段；不要过分担心它；默认只是设置。

【讨论】：

当然，一个花费大量时间到set 的属性（并且不检查这是否是多余的）要么是WTF，要么是非常罕见的东西，而且推理非常好。

【解决方案3】：

早在 90 年代，当我在 x86 汇编程序中进行编程时，规则是 (IIRC) 以避免跳转。 if 语句将作为跳转实现。

所以我的结论是（假设至少一些这些古老的规则仍然适用）避免使用if 并直接分配会更高效。

【讨论】：

这是我正在寻找的答案。谢谢你的 Uwe ✌

【解决方案4】：

我通常会做的是，如果我期待其他任何类型的变量的默认值，我会将其设置为通常不会出现的值。这样，如果值没有改变，那么我知道会发生什么以及如何处理它。它实际上不适用于您的示例，您的问题有点模糊，您的示例无法解释您尝试做什么。

我当然同意 Marc 和 Dan 的说法。

【讨论】：