用編譯型語言去解決腳本語言的性能問題是個不小的機會

前言

• 技術預演第一步很重要，開始錯了後面可能都是白費力氣

原由

• 打包優化是我以前一直想解決的一個問題，修改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環境了直接使用安裝包也是能夠的