用编译型语言去解决脚本语言的性能问题是个不小的机会

前言

• 技术预演第一步很重要，开始错了后面可能都是白费力气

原由

• 打包优化是我以前一直想解决的一个问题，修改webpack源码也是增长缓存和多线程这两个方式juejin.im/post/5def81…
• 前段时间的esbuild使我眼前一亮，提供了一些新的思路，是否是二进制的文件执行效率比nodejs快？
• 使用golang这样编译型是否是会是提高脚本语言执行效率的一种途径，例如用python和node.js写的脚本开发过程比较简单，开发速度很快（相对于一个Java项目）,可是这些脚本一样的一个问题就是执行效率低也是解释型语言通病之一。开发语言没有优劣之分只是区分不一样的应用场景，最快的执行效率，不表明最快的开发效率，最快的开发效率也不表明有最好的生态社区稳定性等等。
• 小结若是用c开发打包脚本是否是更快呢哈哈？

开始

• nodejs有个pkg的打包工具能够将nodejs打包成二进制文件（实际上是一种环境模拟的机制）
• 第一步写个测试两万个文件的读写，用nodejs跑和nodejs打包错了的exe跑（我就错在这一步，当时可能比较兴奋）
• 第二步用pak打包一个webpack4只要注释掉两行代码就能够正确执行了
• 第三步改进脚手架把angular-cli 本地化打包成exe
• 执行构建命令
• 结果是能打包出来，而后效率并无提高

注意事项

pkg打包过程当中本地路径引用的问题必定要注意（例如__dirname是在执行二进制的文件目录下面而不是真正执行的工做目录下面）

value	with node	packaged	comments
__filename	/project/app.js	/snapshot/project/app.js
__dirname	/project	/snapshot/project
process.cwd()	/project	/deploy	suppose the app is called ...
process.execPath	/usr/bin/nodejs	/deploy/app-x64	app-x64 and run in /deploy
process.argv[0]	/usr/bin/nodejs	/deploy/app-x64
process.argv[1]	/project/app.js	/snapshot/project/app.js
process.pkg.entrypoint	undefined	/snapshot/project/app.js
process.pkg.defaultEntrypoint	undefined	/snapshot/project/app.js
require.main.filename	/project/app.js	/snapshot/project/app.js

• 因为前面资源路径引用的问题因此可能须要把某些脚本资源加载到二进制中

"pkg": {    "scripts": "build/**/*.js",    "assets": "views/**/*"  }复制代码

• 技术预演时应该更谨慎一点

收获

• 之后本身写node小工具不须要再依赖本机的node环境了直接使用安装包也是能够的