[翻译]你应该避免的3个Javascript性能错误

若是我告诉你，你知道的一切都是假的，若是你学的一些近几年发布的深受喜好的 ECMAScript 的主要特性，是很容易致使性能问题的，会发生什么。
故事发生在几年前，让咱们回到 ES5 的天真时代...
我深深地记得 ES5 发布的那天，咱们喜好的 Javascript 引入了一些优秀的数组方法，它们是 forEach, reduce, map, filter——这些方法让咱们感觉到语言不断发展，功能愈来愈强大，写代码变得更有趣和流畅，代码变得更通俗易懂。
几乎同时，诞生了 Node.js ，它使得咱们能平稳地从前端过渡到后端，同时真正从新定义了全栈开发。
如今，Node.js ，在 V8 引擎上使用最新的 ECMAScript ，争取被认为是主流的服务端开发语言之一。所以，它须要证实在性能方面是高效的。固然，有不少性能参数须要考虑，没有某种语言的性能能够全部参数都优于其余语言。可是，用开箱即用的方法如上面提到的函数写 javascript 对你的应用性能的影响究竟是有利仍是有害呢？
此外 ，javascript不只仅是为了展现视图而被认为是客户端开发的合理方案，由于用户的电脑性能会变得更好，网络会更快，可是当咱们须要一个超高性能的应用或者很是复杂的应用时，咱们能依赖用户的电脑吗？
为了测试这些问题，我尝试比较几个场景并深刻理解个人实验结果，我在 Node.js v10.11.0、Chrome浏览器、macOS上作的测试。

1.遍历数组

我作的第一个场景是对一个 10万条数据的数组求和。这是现实中一个有效的方法，我从数据库中获取了一个列表并求和，没有额外的 DB 操做。
我用 for , for-of, while, forEach, reduce 比较了在随机的 10万条数据中求和，结果以下：

For Loop, average loop time: ~10 microseconds
    For-Of, average loop time: ~110 microseconds
    ForEach, average loop time: ~77 microseconds
    While, average loop time: ~11 microseconds
    Reduce, average loop time: ~113 microseconds

从 google 上查如何作数组求和时，reduce 是推荐的最好的实现方式，可是倒是性能最差的。个人必用方法 forEach 性能也不是很好。即便是最新的 ES6 方法 for-of ，只是提供了最差的性能方法。它比旧的 for 循环方法(也是性能最好的方法)差了 10 倍。
最新的和最推荐的方法怎么可使得 Javascript 变得如此慢，形成这个的缘由主要有 2 个。reduce 和 forEach 须要一个执行一个回调函数，这个函数被递归调用并使堆栈"膨胀",以及对执行代码进行附加操做和验证。

2.复制数组

复制数组看起来不是一个有趣的场景，但这是不可变函数的基石，它在生成输出时不会修改输入。
性能测试一样出现了有意思的结果——当复制 10 万条随机数据时，用老方法仍是比新方法快。用 ES6 的扩展运算操做 [...arr] 和 Array.from, 加上 ES5 的 map 方法，arr.map(x=>x) 性能都不如老方法 arr.slice() 和 链接方法 [].concat(arr)

Duplicate using Slice, average: ~367 microseconds
    Duplicate using Map, average: ~469 microseconds
    Duplicate using Spread, average: ~512 microseconds
    Duplicate using Conct, average: ~366 microseconds
    Duplicate using Array From, average: ~1,436 microseconds
    Duplicate manually, average: ~412 microseconds

3.对象迭代

另外一个常常遇到的场景就是对象迭代，一般就是咱们不能根据特定的 key取值，而必须遍历 JSON 结构 或者 Object。咱们有老方法 for-in (for(let key in obj))，也有新方法 Object.keys(obj) 和 Object.entries(obj)。
咱们用上述方法，对 10 万个对象，每一个对象都包含 1000 个随机的 keys 和 values 进行性能分析。结果以下：

Object iterate For-In, average: ~240 microseconds
    Object iterate Keys For Each, average: ~294 microseconds
    Object iterate Entries For-Of, average: ~535 microseconds

出现这样结果的缘由是，后两种方案建立了可枚举的数值组，而不是在没有 keys 的状况下直接遍历数组。可是最终的结果仍然值得关注。

结论

个人结论显而易见——若是性能对你的应用很关键，或者你的服务须要处理一些过载，那么使用酷的，可读性更高的，更简洁的方法会对你的应用产生重大的性能影响——可能会慢 10 倍！
以后，在盲目跟随新趋势以前，先确保这些新方法是否知足需求，对于小应用，快速迭代和高可读性对代码是完美的，可是对于压力大的服务器和庞大的客户端应用，可能不是最佳实践。
原文：https://hackernoon.com/3-javascript-performance-mistakes-you-should-stop-doing-ebf84b9de951

最后

• 点右下角「在看」，让更多的人也能看到这篇内容，好东西一块儿分享...
• 欢迎加我微信(winty230)，拉你进技术群，长期交流学习...
• 欢迎关注「前端Q」,认真学前端，作个有态度的技术人..