What I meant to say was not to use asm.js as target for compilation, but rather implementing performance-critical module in asm.js subset and get the extra performance out of V8. Sort of like how Rusha[1] did it.

[1]: https://github.com/srijs/rusha/commit/e435ccdd709b6a3374879c...

Another example I posted yesterday: http://wry.me/hacking/Turing-Drawings/

Crossing the JS to C++ barrier is not free [1]. Compiling the C to asm.js allows everything to live in the VM and avoids this cost.

[1] https://github.com/felixge/faster-than-c is a talk by a longtime node contributor on this topic.

Calling asm.js code is not free either, it's worth mentioning. I measured it at (very) roughly 2ms/call for the code I posted yesterday. (At asmjs.org they mention they intend to address this.)

2ms is obscenely slow for a no-op function call. If correct, that needs to be treated as a bug by the asm.js team.

It's not a no-op, it has to check types and maybe convert representations, much like a C/C++ FFI (but with more freedom for the implementor, who's not committed to the C ABI, so there's potential to go faster than a C FFI).

But I agree it needs attention, and apparently so do the Firefox devs. In http://wry.me/hacking/Turing-Drawings/ the asm.js version ran much slower than the regular JS version, until I adapted it to make fewer calls. The slowness also makes some other uses I've thought of impractical.

(The figure I gave was not carefully measured; just enough to say "yep, that'd account for why this is amazingly slow".)

It could help solve the cross platform extension problem. Windows users often get left out. This would make node.js more like java as a write once run anywhere platform.