Chrome 39 JavaScript 性能异常
Chrome 39 JavaScript Performance Anomaly
我 a jsPerf test 看看在 JavaScript 的函数中使用参数或局部变量是否有任何性能差异。
在 Firefox 34 中，几乎没有区别。然而，在 Chrome39 中，编译器似乎做了很多坏事。查看这些结果：
谁能解释为什么会这样？
首先，对于一个试图衡量参数与局部变量性能行为的基准测试，你在每种情况下都太多了——你一次又一次地分配一个闭包，你从对象字面量分配对象，你使用 for-in 循环。所有这些操作都比局部变量访问昂贵 。它们的成本包含并隐藏了访问具有的任何小成本变量。
现在您看到的异常是由于 V8 没有快速路径来创建包含文字的闭包：有 FastNewClosureStub 但它仅在闭包中没有文字时使用[1] .与第二种情况相比，这使得第一种情况下的闭包分配成本更高 - 您会在分数中看到这一点，因为闭包分配是基准测试的主要部分（它为每个 op 分配一个闭包).
如果您 "hide" 文字创建[2] 到一个单独的函数中，您将看到异常消失。注意：这种隐藏并不能使基准测试更具代表性：它仍然不是衡量你想衡量的东西。
总的来说，试图在基准测试中捕获变量访问的性能特征非常困难，因为即使在非优化（基线）编译器生成的代码中，这些通常也是最快和最小的操作之一。在最常见的情况下，当没有变量被捕获并且作用域不包含 with、eval 或 arguments 对象时——参数和局部变量访问之间没有区别，两者都向下编译进入单个内存负载。
[2]http://jsperf.com/variable-vs-variable-passed-as-an-argument-to-a-self-in/3
我 a jsPerf test 看看在 JavaScript 的函数中使用参数或局部变量是否有任何性能差异。
在 Firefox 34 中，几乎没有区别。然而，在 Chrome39 中，编译器似乎做了很多坏事。查看这些结果：
谁能解释为什么会这样？
首先，对于一个试图衡量参数与局部变量性能行为的基准测试，你在每种情况下都太多了——你一次又一次地分配一个闭包，你从对象字面量分配对象，你使用 for-in 循环。所有这些操作都比局部变量访问昂贵 。它们的成本包含并隐藏了访问具有的任何小成本变量。
现在您看到的异常是由于 V8 没有快速路径来创建包含文字的闭包：有 FastNewClosureStub 但它仅在闭包中没有文字时使用[1] .与第二种情况相比，这使得第一种情况下的闭包分配成本更高 - 您会在分数中看到这一点，因为闭包分配是基准测试的主要部分（它为每个 op 分配一个闭包).
如果您 "hide" 文字创建[2] 到一个单独的函数中，您将看到异常消失。注意：这种隐藏并不能使基准测试更具代表性：它仍然不是衡量你想衡量的东西。
总的来说，试图在基准测试中捕获变量访问的性能特征非常困难，因为即使在非优化（基线）编译器生成的代码中，这些通常也是最快和最小的操作之一。在最常见的情况下，当没有变量被捕获并且作用域不包含 with、eval 或 arguments 对象时——参数和局部变量访问之间没有区别，两者都向下编译进入单个内存负载。
[2]http://jsperf.com/variable-vs-variable-passed-as-an-argument-to-a-self-in/3