This is a metabug for maximizing Emscripten performance. There are two dimensions: - throughput: compile it to something that's as close as we can (staying safe) to what a C compiler would have done on the original code - startup: minimize startup latency, which includes both time before we run any code at all, and time until we're running smoothly (we can be compiling and running at the same time)

Alon, Luke, given that we're moving to Asm.js for emscripten perf, do the bugs here actually still apply?

I don't think we are moving to asm.js whole hog. First, asm.js is a research project, and second, it will possibly never support all the compiled code we can generate (e.g., we have various JS tricks for things like longjmp, C++ exceptions, and it is not clear yet how asm would handle them). Also, optimizing for emscripten-type code will help other compilers that are not asm. So I think the bugs here definitely do still apply. I would agree they are slightly less of a priority though.

It still makes sense to optimize the patterns in a general non-asm.js scenario. That is, from a non-asm.js perspective, Emscripten mostly just generates a bunch of independently highly-optimizable patterns.

Whoa, Alon already beat me.

I would like to point out, re: comment 2, that we may eventually add support to asm.js for exception handling (that is, via a restricted patterned use of try/catch).

Fixed by asm.js, so not a games priority any more; JS guys should probably go through the dependent bugs and see if they're still relevant.