The ELIMINATE_DUPLICATE_FUNCTIONS support was contributed by Tableau Software, by the team I'm on. It's quite expensive processing wise, but is worth a shot seeing if your code base benefits from it. Our usecase leverages a lot of shared pointer based templated classes, which tends to create a lot of delete functions that boil down to free(this);

2 other points I'd add to this overall:

1) Can't emphasize enough how bad exception support is for size, expect in the neighborhood of 30% size increase. This is due to needing to handle all of the possible ways functions can return. Even with exception support disabled, you can still throw them, you just can't catch them in C++ land.

2) goto's. There's a few good reasons to use these, especially in code that needs to make sure cleanup code always runs. Emscripten supports that with a couple different code constructs, pretty much all of which cause a significant amount of bloat. We've saved ~100k in some cases by specifically targeting some 3rd party code that made use of them and rewritting them to not have gotos.

> Even with exception support disabled, you can still throw them, you just can't catch them in C++ land.

Is something printed in the console under emscripten if an exception is thrown?

It gets converted into a Javascript exception, which will at least give you the Emscripten converted function it was thrown in.

Interesting. Thank you.

"The emscripten version is even smaller than the native version after compression, impossabru! I actually didn’t expect this myself (last time I did such comparisons the emscripten versions came out about 10..20% bigger)"

This is because JavaScript is alpha-numeric and is easier to compress than binary. There are a relatively 'small' number of characters in the alpha-numeric range, so they can be mapped together easier than the wider range of binary data.

Can someone ELI5 what asm.js is? I've tried Googling it multiple times now and every time I basically give up because I can't relate to anything it's talking about when all they use is buzzwords.

This (funny and accessible, don't worry) talk by Gary Bernhardt is what helped me understand asm.js for the first time: https://www.destroyallsoftware.com/talks/the-birth-and-death...

A language which is a strict subset of JavaScript. The purpose is to write compilers from C to asm.js, which then allows you to write C code and it compiles to something that can run on the browser

... and that strict subset of JS can be compiled into very efficient native code.

Those recommendations together almost sound like "write C in C++".

A lot of C++ coding styles do something like that. I guess because C++ is so large.

asm.js really seem to be a good solution, I hope some day it will be used to do more than web games. But at the same time, the vision of the future of compiling everything in javascript is pretty scary.

I think WebAssembly will replace asm.js soon.

Think of WebAssembly as a binary encoding of asm.js. You'll be able to deliver the same program in either format. Asm.js will still be around to support older browsers.

> Asm.js will still be around to support older browsers.

I don't see a need for this since WebAssembly will provide a polyfill.

The polyfill won't benefit from browser based JIT compilation. If you're concerned with performance, even for browsers that don't support wasm, you'll want to switch to asm.js.

I sort of think about it the other way round, actually.

Not sure what you mean? Asm.js was defined a couple of years before Web assembly

Yes, but it was defined after actual assembly/low level languages like BLISS. So it was defined as a way of doing something "assembly-like" (or BLISS-like, or BCPL-like) in an environment that didn't allow for such code.

nit: the C style example, should use /* These kind of comments */ not // these kind of comments.

C99 supports //.

C89 standard does not.

It is 2016.

Why evolve a language if you can't use any the new features?

So? If you're still using C89 you're doing it wrong.

Perhaps, portability?

Mostly Windows. It's only recently that Microsoft reluctantly (and only recently) acknowledged the existence of C99 (which isn't fully compatible with C++, their preferred development language). So maybe in three more years we'll all be able to move to C99.