擅长:python、mysql、java
<p>这可能是对<a href="http://en.wikipedia.org/wiki/Branch_misprediction" rel="nofollow">branch misprediction</a>进行优化的尝试。现代的CPU是大规模流水线的;它们可以预先执行10条或更多条指令。一个近乎随机的有条件的分支有一半的时间是单向的,而另一半的时间则意味着CPU将不得不在一半的时间内抛出10条指令,这使得你的工作速度慢了5倍。至少在CPython中,分支预测失误的大部分成本都隐藏在开销中,但是您仍然可以很容易地发现它们至少会增加12%的时间,如果不是C中预期的500%</p>
<p>另一种选择是,作者正在优化一些更不相关的东西。在70年代和80年代的硬件上,用位操作代替算术运算通常会导致巨大的加速,这是因为算术逻辑单元很简单,而且编译器没有进行太多优化。即使是那些实际上不希望得到同样的加速的人,也已经将所有标准的玩弄技巧内化了,不用想就可以使用它们。(或者,当然,作者可能只是从C、Scheme或其他语言移植了一些代码,而这些代码可能是几十年前编写的,当时这种优化产生了巨大的影响。)</p>
<p>无论如何,这段代码几乎肯定是在错误的地方进行了优化。定义一个在内部循环中每次调用的函数,而不是只在那里内联一行表达式,增加的开销远远超过12%。代码使用<code>step = lambda x: …</code>而不是<code>def step(x): …</code>这一事实强烈地表明作者对Python并不熟悉,也不知道如何对其进行优化。如果您真的想让它更快地运行,几乎可以肯定的是,有很多事情会比您为<code>step</code>使用的实现产生更大的差异。在</p>
<p>也就是说,对于任何你不确定的优化,正确的做法就是测试它。两种方法都可以实现,使用<code>timeit</code>来查看差异,如果不理解结果,可以使用Python级别的探查器或硬件级别的性能计数器(例如,通过<code>cachegrind</code>)或其他方法来获取更多信息。通过对原始代码的快速测试,使用IPython的<code>%timeit</code>对原始代码进行了各种各样的测试,得到的结果从.92x到1.08x倍不等。换句话说,这似乎是一场洗礼</p>