Pkg: Performance comparison of generated binary vs running through node

[adnan-kamili]

I suppose running the binary instead of node with js files will be slow as v8 makes many optimizations which may not be possible at compile time. Are their any statistics of how slow this compiled code runs in comparison to the default interpretted (JIT) way running node apps

[vmakarevich-sugarcrm]

As far as I understand result bin contains node altogether with cached code data produced by https://nodejs.org/api/vm.html#vm_class_vm_script. Am I right? It would be nice to have a little info related to implementation details.

[rla]

I benchmarked this for an Express-based web app with Node 8.0.0 and found that the compiled version was 31% slower than the plain version under Crankshaft. With Ignition+TurboFan the difference was only 1.4%. More info: https://github.com/rla/pkg-express-benchmark

[igorklopov]

Good job, @rla! I will try to address that slowdown.

[igorklopov]

@rla. Pkg defaults to stripping the source code of root package (index.js in your case). If you add -d option to pkg command line you see The file was included as bytecode (no sources). That slowdown is known and reasonable tradeoff for stripping source code, because Crankshaft can not optimize without source code. Btw i am really surprised that it is as low as 31%.

I am sure the results will get much better if you make pkg put the source of index.js into executable. In order to do it, you can remove "private": true and add "license": "MIT" to package.json (it is one of ways to override that default so far).

[rla]

@igorklopov, I have updated the benchmark. With source included the difference for Crankshaft decreases to 1.1%. I would be nice if this gets documented in README otherwise users would be throwing away over 30% of performance if they hit similar conditions (no license property or have private: true property value).

[igorklopov]

Right! Thanks! 👍