I'm using the chrome dev tools Network panel to observe relevant events:
* At the 1.25 second mark, all the necessary files (wasm, data, js, ...)
have been downloaded.
* - WASM processing seems to happen here (cpu utilization goes up to
100%) -
* At the 4.25 second mark, emscripten
A lot of good stuff has happened since April. The main issue has on the
browser side, where things are now a lot better. In particular, baseline
compilers are now common, like V8's Liftoff,
https://v8.dev/blog/liftoff
That should be enabled in Chromium 71, but you can confirm in
chrome://flags.
I've made a thread back in April, with a similar focus:
https://groups.google.com/forum/#!searchin/emscripten-discuss/still$20slow%7Csort:date/emscripten-discuss/Ft3UT0PHX_w/gXUMRN4hAgAJ
While somewhat useful, I think that thread was a bit side-tracked, because
instead of discussing why WASM
I believe that's normal, yes. For function pointer cast emulation we run
binaryens fpcast-emu pass. It turns each indirect call into a call like
that, so you will see them on the stack. This happens after emterpretify,
and there should be no interactions between them that I can think of atm.
On
Hi,
My current Python+Emterpreter app (https://renpy.beuc.net/) sometimes
crashes unexpectedly, e.g. when going back to the browser tab after a
few minutes of inactivity.
I'm still trying to figure out where that comes from, but something in
the JS stack trace intrigues me:
...
emterpret