I was thinking that Emterpreter could be used for non-performance-critical 
functions to decrease file size because the bytecode should be more compact 
than JavaScript. In tests with Em-DOSBox, Bochs and JSMESS it does indeed 
decrease total file size for .js plus .mem, but it increases total file 
size when they are compressed with gzip -9. It seems the startup time 
benefit comes from not needing asm.js compilation for emterpreted functions.

Emterpreter sync has been great for Em-DOSBox. I used it with a whitelist 
to enable various DOSBox functionality which is written in a way that's 
incompatible with the Emscripten main loop paradigm. The performance 
penalty is small because Emterpreter is used selectively for functions 
which aren't performance-critical. Here is a blog post about how I did 
this: 
http://dreamlayers.blogspot.ca/2015/02/fixing-hard-problem-in-em-dosbox-using.html

On Thursday, 26 February 2015 21:10:06 UTC-5, Alon Zakai wrote:
>
> The Emterpreter option on incoming
>
> https://github.com/kripken/emscripten/wiki/Emterpreter
>
> is now considered stable (large amounts of testing over the last few weeks 
> have hopefully ironed out any significant issues). Basically, this new 
> option lets you run all or part of your application inside an interpreter, 
> which lets you improve startup time or run synchronous code. See the link 
> for more details, links to some blogposts are inside as well.
>
> If this is relevant to your project and you try it out, I'd be very 
> interested in your feedback.
>
> - Alon
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to