1. Normal output, asm.js, no memory growth. Maximal speed, fixed memory size.
2. Memory growth. As the article mentions, asm.js no longer supports this, but Emscripten does. It just removes the 'use asm'.
3. Split memory. As the article mentions, this is non-asm.js. This supports not just growing and shrinking memory, but allocating each chunk of memory separately, leading to flexibility similar to that of Cheerp.
The article compares 1 and 3, but not 2. In practice, almost all Emscripten users use 1, a small amount use 2, and as far as I know almost no one uses 3. Also, 2 would start up much faster than 1, and run much faster than 3, so it would be an interesting comparison to Cheerp.
Regarding startup time, there are two things that I think should have been measured:
1. Large programs. The largest they test is the Bullet physics library, which is still quite small.
2. Execution of the first few frames. Non-asm.js code, like Cheerp output, is compiled dynamically. This generally means that startup is fast, then the first few frames are very slow, then it eventually gets smooth. The measurements in the blogpost appear to ignore that.
Both of those things - larger programs, and more sophisticated measurements of startup speed - are present in the open source Massive benchmark [1]. It would be interesting to see Cheerp compared to Emscripten on that (and also on the 2nd mode mentioned earlier).