node.js是否真的不优化对 .slice.call（参数）的调用？
在蓝鸟文件中 ，他们将此作为停止优化的反模式。他们称之为参数泄漏 ，
function leaksArguments2() { var args = [].slice.call(arguments); } 我在Node.js中一直这样做 这真的是个问题吗？ 而且，如果是这样，为什么呢？
假定只有最新版本的Node.js
免责声明：我是维基页面的作者
如果包含的函数被称为很多（很热），这是一个问题。 优化编译器（曲轴）不支持泄漏arguments函数。
通常当一个function很热时，它会被优化。 但是，如果函数包含泄漏arguments等不受支持的function，那么作为热门函数将无济于事，它将继续运行缓慢的通用代码。
与未优化function相比，优化function的性能是巨大的。 例如考虑一个函数，将3个双打加在一起： http : //jsperf.com/213213213 21x的区别。
如果加6个双打呢？ 29倍的差异一般来说，函数的代码越多，该函数在非优化模式下的惩罚越严重。
对于node.js这样的东西通常实际上是一个巨大的问题，因为任何CPU时间完全阻止服务器。 只需优化节点核心中包含的urlparsing器 （我的模块在节点自己的基准testing中速度提高了30倍），就可以将基于查询数据库的基准testing中的每秒mysql-express的请求从70K rps提高到100 k rps。
好消息是节点核心知道这一点
这真的是个问题吗？
对于应用程序代码，不。 几乎所有的模块/库代码，没有。 对于蓝鸟这样的图书馆来说，这个图书馆在整个代码库中都是普遍使用的。 如果你在应用程序中使用了非常热门的function，那么也许是的。
我不知道细节，但我相信蓝鸟作者可信的是，以文档中描述的方式访问arguments会导致v8拒绝优化函数，因此蓝鸟作者认为值得使用构build时macros得到最优化的版本。
只要记住引起节点的延迟数字。 如果你的应用程序做了一些有用的事情，比如与数据库或者文件系统交stream，那么I / O将是你的瓶颈，优化/caching/并行化将会比上面的v8级内存微优化支付更多的利益。