Question

问题很简单，CalledOften1和CalledOften2

之间的关系更快

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

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

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

Answer 1

我更倾向于衡量这些问题，而不是猜测：

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

所以他们几乎一样。如果有的话，更简单的方法也更快。

Answer 2

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

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

话虽这么说，第二个例子的简化指令集，以及更简单和更多可维护，很可能更快，因为避免了分支并减少了指令数量。单bool的分配是一种非常快速的操作。如果你真的需要知道它可能有多快，我会亲自描述一下。但是，我怀疑在任何情况下都要快得多。

Answer 3

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

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

Answer 4

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

Answer 5

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

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

我的两分钱，布赖恩

Answer 6

过早优化是万恶之源。使用最明确表达你意图的那个。

（我猜测读取+分支比写入更昂贵，但实际上并不知道CLR。重要的是计算机的速度呈指数增长，而程序员则不然。性能瓶颈的算法改进是值得探索的，几乎没有可测量的恒定时间改进本身并不是。）

更快的分配或检查bool值

6 个答案: