Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code

Issue 29414555: Noissue - [emscripten] Added -fno-exception flag, reduces build size by 20% (Closed)

April 16, 2017, 7:16 a.m. by Wladimir Palant
April 18, 2017, 8:53 a.m.
hub, Felix Dahlke
Base URL:


This is mostly FYI, the change is quite uncontroversial - we removed all exception processing a while ago. libcxx is still using exceptions however, so this change has significant impact - 20% reduction in build size. I compared the builds and the difference comes mostly from libcxx dragging in lots of dependecies in order to handle exceptions, including stream I/O and even pthreads. Plus, quite a few globals went away and do not need to be initialized any more. Also, a few functions could be optimized a bit better now that calls cannot throw. But we have to be careful using std::vector of course, no length checking will be performed now (not that an exception thrown would have saved us before).

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+1 line, -1 line) Patch
M compile View 1 chunk +1 line, -1 line 0 comments Download


Total messages: 4
Wladimir Palant
April 16, 2017, 7:16 a.m. (2017-04-16 07:16:16 UTC) #1
Wladimir Palant
I checked and not having exceptions in libcxx doesn't mean that std::vector will ignore length ...
April 16, 2017, 2:06 p.m. (2017-04-16 14:06:23 UTC) #2
LGTM only because it very positively influences the size of the result and it does ...
April 18, 2017, 8:02 a.m. (2017-04-18 08:02:10 UTC) #3
Wladimir Palant
April 18, 2017, 8:53 a.m. (2017-04-18 08:53:07 UTC) #4
On 2017/04/18 08:02:10, sergei wrote:
> LGTM only because it very positively influences the size of the result and it
> does not hurt right now (or we are not aware about it :) ).

Well, we explicitly made sure not to use exceptions, these are known to be slow
with Emscripten. We are also careful not to trigger any exceptions in STL. So we
are only being consequent.

> Basically, I think we are not using API of C++, merely of C, so, if the size
> so important, maybe it could be reduced even more by not linking with libc++
> linking only with libc. It will require to implement few functions, like
> `operator new/delete` (and for arrays), some handlers (like atexit, destroying
> global variables, which is likely not relevant for us) and maybe a couple of
> more functions. It's pretty popular technique among developers for
> microcontrollers, from where we could borrow the implementation of functions
> libc++.

This might actually be worth doing. As I've noticed, we are currently pulling in
libcxxabi as a dependency for no good reason - this is mostly due to new/delete
operators which would be easy to replace by our own trivial implementations.
I've already verified (by messing with Emscripten code) that removing that
dependency would reduce the size by another 5 kB - that's around 3%. If doing it
without changing Emscripten isn't too complicated, it might be worth it - but we
would have to get rid of all libcxx dependencies then, meaning std::vector as

Powered by Google App Engine
This is Rietveld