更快的分配或检查布尔值答案

【问题标题】：Faster assignment or check for bool values更快的分配或检查布尔值
【发布时间】：2011-05-22 11:12:06
【问题描述】：

问题很简单，CalledOften1和CalledOften2之间哪个更快

    class MyTest
    {
        public bool test = false;
        void CalledOften1()
        {
            if (!test) test = true;
            DoSomething();
        }
        void CalledOften2()
        {
            test = true;
            DoSomething();
        }
    }

编译器是否已优化（如果可能）以避免将来分配测试（如果它已经是真的）？

更新： 这个问题只是一个信息，如果我可以写test=true，我不会使用if(bla)样式，我更喜欢代码可读性。

【问题讨论】：

找出哪个更快的唯一方法是双向运行，看看哪个更快。您已经以两种方式编写了代码；是什么阻止你运行它？
Mh 我不知道如何检查每项工作所需的毫秒数，我敢肯定在这里写这种类型的问题会更快
那么你有一个更大的问题：你不知道如何成功地进行性能分析。除非您打算每次遇到性能问题时都向社区询问，否则我的建议是学习如何进行性能分析。简而言之，以下是您进行性能分析的方法：(1) 设定以客户为中心的性能目标，(2) 编写并执行真实的测试，根据这些目标衡量应用程序的性能，(3) 如果您还没有达到目标，请学习使用分析器找到最慢的东西。 (4) 修复它。 (5) 返回步骤 (2)。
如果您想知道哪个更快，但您不知道如何使用高性能计时器，那么您可以（1）学习使用高性能计时器，或者（2 ) 编写一个循环运行代码十亿次；拿着秒表坐在那里等待它完成，然后将得到的秒数除以十亿。

标签： c# boolean variable-assignment

【解决方案1】：

我更喜欢衡量这类问题而不是猜测：

CalledOften1：每秒 5200 万次操作
CalledOften2：每秒 5300 万次操作

所以它们几乎相同。如果有的话，更简单的方法也更快。

【讨论】：

嗯。您是如何准确衡量手术次数的？ 5200 万对 5300 万？！？
@warriorpostman：一种方法是循环运行 100,000,000 次，看看需要多长时间。将 100,000,000 除以秒数得到每秒的执行次数。在我做的测试中，我也先做了一些热身循环。我怀疑大部分时间都花在测试循环条件和递增循环变量上。

【解决方案2】：

这是过早优化的完美示例。

如果您想每次都将test 设置为true，只需设置即可。不要为了理论上的加速而使您的代码复杂化。

话虽如此，第二个示例的精简指令集，以及更简单和更可维护，由于避免了分支和减少了指令数。 bool 的单个分配是一个非常快速的操作。如果你真的需要知道它可能有多快，我会自己分析一下。但是，我怀疑在任何情况下都足够快。

【讨论】：

【解决方案3】：

我希望第二个版本会稍微快一些，因为它不涉及任何分支。它还更清楚地表达了“确保变量为真，无论以前是什么”的意图。然而：

我怀疑这很重要
上下文中任何数量的实际更改都可能导致结果发生变化（包括您的代码或您运行的框架版本）
先写最清晰的代码，再优化
在您决定更改任何内容之前，在实际条件下根据您的真实代码对此进行基准测试

【讨论】：

你怎么回答得这么快？请告诉我秘密！我知道谈论优化毫无用处，只是对此感兴趣，因为有人说我“在这种情况下写内存更慢”
@Fire-Dragon-DoL：有几个人在我之前得到了答案 :)
@Fire-Dragon-DoL：最佳答案（无论是哪种情况，根据任何标准）难道不是被标记为接受的答案吗？为什么痴迷于速度？ :-)
我的意思是，这个问题和它的答案会存在很多年，而发布时间上的一分钟差异将远远低于准确性、完整性、清晰性，甚至是正确的拼写，以确定哪个答案应该放在首位。
@Fire：你不知道 Jon Skeet 不再在这里回答问题了吗？它只是一个人工智能非常好的机器人！

【解决方案4】：

编译器只优化在编译时确定的东西。这是在运行时更改的，所以答案是否定的。如果您检查常量，编译器可以优化。 CalledOften1 更快，但幅度很小，您不会注意到。这是一种你应该避免的微优化。

【讨论】：

【解决方案5】：

如果我不得不猜测，我会说 CalledOften2 更优化，因为没有进行逻辑测试操作。

最后，如果您正在考虑这一级别的优化，那么您的应用程序可能会尽可能快地运行。您从此类优化中获得的任何性能提升都可能永远不会被任何人注意到。

我的两分钱，布赖恩

【讨论】：

【解决方案6】：

过早的优化是万恶之源。使用最清楚地表达您的意图的那个。

（我猜读+分支会比写更昂贵，但并不真正了解 CLR。重要的是计算机的速度呈指数增长，而程序员却没有。性能瓶颈的算法改进值得探索，而几乎无法衡量的恒定时间改进本身就不值得探索。）

【讨论】：

回答问题或写信给 cmets。