大佬教程收集整理的这篇文章主要介绍了Node.js 性能调优之代码篇(一)——使用原生模块，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
由于历史原因，石墨后端的框架选型是 koa@1+(generator|bluebird)+sequelize。这个选型并没有什么问题，也很常见，但是到了滥用的地步。就像封面图表达的那样，排除掉 sequelize 这个不得不用的模块，从 cpuprofile 角度讲讲为什么我认为应该用 async/await+Promise 替代 co+generator|bluebird。
我的观点是：使用原生模块具有更清晰的调用栈。
下面用 4 个例子对比，看下相同逻辑不同代码生成的 cpuprofile 中调用栈的信息。
async.js
截图如下：
可以看出：asyncWrap 中调用了 B 函数，B 函数调用了 A 函数，A 函数中 resolve 了一个值。asyncWrap 中还调用了 stopProfiling 函数。
co.js
截图如下：
：调用栈非常不清晰，太多没有用的 co 相关的调用栈。如果 n 个 generator 层层嵌套，就会出现 n 倍的 (anonymous)->onFullfiled->next->toPromise->co->Promise->(anonymous) 调用栈。如果你读过 co 的源码可能知道，这是 co 将 generator 解包的过程。其实这个可以通过 yield generator -> yield* generator 来解决。
co_better.js
：相比 co.js 调用栈就清晰了很多，不过相比用 async/await 还是多了些 onFulfilled、next。
co_bluebird.js
：相比较 co_better.js，调用栈中多了许多 bluebird 模块的无用信息。而且这只是非常简单的示例代码，要是复杂的业务逻辑代码生成的 cpuprofile，几乎没法看了。
结论：使用 async/await+Promise，具有更清晰的调用栈，让分析 cpuprofile 时不再痛苦。 聪明的你会问： 1. bluebird 太好用了，完全放弃不下啊？你可以逐步替换嘛，大部分场景多写点代码就可以避免使用 bluebird 了，比如 bluebird 的 .all .map .filter 啥的都可以用 Promise.all 去实现，实在实现起来复杂的那就先用着 bluebird 呗。 2. 我现在代码中大量使用了 yield+generator 怎么办？ 3. 性能比较呢？node@8 下 async/await 完胜 co。 https://medium.com/@markherhold/generators-vs-async-await-perfoRMANce-806d8375a01a 作业 请读者自行尝试 async/await+bluebird 的情况。 async_bluebird.js
结论：调用栈比 co_blueblird.js 的还难懂……黑人问号???
往期精彩回顾
如您有任何问题，请联系优才小编：
15201480058
以上是大佬教程为你收集整理的Node.js 性能调优之代码篇(一)——使用原生模块全部内容，希望文章能够帮你解决Node.js 性能调优之代码篇(一)——使用原生模块所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。
