V8 is going to switch to a new compiler architecture after 5.8 branch cut

I am curious about the possibility of this leading to source code protection in Electron.<p>The Electron team declined to support source code protection, judging it too difficult to implement. [0] NW.js supports the feature but with severe limitations that the Electron team understandably did not want to replicate. [1]<p>Roger Wang of NW.js fame recently tweeted that the NW.js implementation is about to get a whole lot better due to this new compiler landing in V8. [2]<p>Could this new development in V8 put source code protection back on the table for Electron? I posted this question to the official Electron discussion forums too a few days back, but I&#x27;d be curious to hear more input on the topic, thus posting it here as well. [3]<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;electron&#x2F;electron&#x2F;issues&#x2F;3041" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;electron&#x2F;electron&#x2F;issues&#x2F;3041</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;nwjs&#x2F;nw.js&#x2F;wiki&#x2F;protect-javascript-source-code-with-v8-snapshot" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nwjs&#x2F;nw.js&#x2F;wiki&#x2F;protect-javascript-source...</a><p>[2]: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;wwr&#x2F;status&#x2F;831691865850130432" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;wwr&#x2F;status&#x2F;831691865850130432</a><p>[3]: <a href="https:&#x2F;&#x2F;discuss.atom.io&#x2F;t&#x2F;source-code-protection-via-new-v8-compiler&#x2F;39533" rel="nofollow">https:&#x2F;&#x2F;discuss.atom.io&#x2F;t&#x2F;source-code-protection-via-new-v8-...</a>

Finally! Congratulations to the V8 team for completing the switch to a sane compilation pipeline. :)<p>Hopefully this will lead to many more simplifications in the future.<p>Does anyone know which optimizations finally catapulted Ignition+Turbofan ahead of FullCodeGen+Crankshaft in terms of performance?

And this is how you can try it out now in Chrome Canary: <a href="https:&#x2F;&#x2F;v8project.blogspot.com&#x2F;2017&#x2F;02&#x2F;help-us-test-future-of-v8.html" rel="nofollow">https:&#x2F;&#x2F;v8project.blogspot.com&#x2F;2017&#x2F;02&#x2F;help-us-test-future-o...</a>

Can anyone speak to what sort of impact this might have on NodeJS? Will it be difficult for the project to migrate to that version? Is it expected to break packages that rely on C bindings?

Performance, performance, all the talk about performance. What about memory footprint?<p>Apparently Ignition helps a bit, but still… even the baseline memory usage of Node.js and Chromium is bad. Just open a node REPL, its resident set size is 2x the size of a ruby&#x2F;python REPL, about 10x the size of luajit.

I wonder how this will effect performance for games&#x2F;realtime stuff as that seems like the weak point for JS from the user side, although realistically it&#x27;s probably more of a GC problem. Seems like most of the test websites are reasonably static - do a bunch of stuff once at startup&#x2F;do a bunch of stuff on user input so your compilation overhead ends up being fairly large whereas with realtime stuff&#x2F;games I&#x27;d expect it looks more like the octane benchmark....

I&#x27;m a sucker for interpreter designs, and the new Ignition bytecode interpreter looks nice:<p><a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;11T2CRex9hXxoJwbYqVQ32yIP...</a>

Will performance improve across the board, or is the new architecture targeting common patterns believed to be slow, like heavy use of closures &amp; promises, or getting functional calls like map into the same performance range as a for loop?