hello_world.cpp generates much more JavaScript than necessary

[abarth]

When compiling hello_world.cpp, the generated JavaScript contains thousands of lines of code, the vast majority aren't needed to execute hello_world.js. Instead, the generated JavaScript should contain only what's needed.

(I'm a new emscripten contributor, and I'm filing this bug mostly to ask whether work on this topic would be valued by the emscripten community. If so, I'll be happy to send pull requests. Thanks!)

[kripken]

Yes, it would be good to improve this, and contributions would be very welcome of course. Currently the best we can do is fully optimize+run closure, -O3 --closure 1, which should remove all unneeded code. But, we still have reasons why even that is not tiny,

1. hello_world.cpp uses printf or iostream or such, which means we must include parts of libc (and libc++ for iostream). LLVM gets rid of parts not actually used, but still quite a bit remains. And that pulls in our JS filesystem support (in-memory filesystem), which closure can get rid of parts not actually used, but still, just initializing the filesystem (creating /tmp and other standard dirs, standard streams, etc.) takes some code.
2. We export various useful APIs through closure, like getValue, Pointer_stringify, etc. This allows handwritten code from outside to use it. But it keeps some code alive that you might not use.
3. We assume code may likely run in a browser, and include our Browser object by default, etc. We detect at runtime if we are in a browser, worker, node, other js shell, etc., so we end up including code for all of them (the browser part is the biggest, though).

It's hard for me to see how to fix 1. Perhaps we could have a build flag "minimal filesystem" which includes just enough for printf, and nothing more?

2 could be improved by adding a build option to specify an explicit list of what to export. Right now EXPORTED_FUNCTIONS is the list of compiled functions to export, we could have a list of JS support functions as well.

3 could be improved by having compile-time options for where the code is intended to run. Although, this adds complexity and is a little sad, as it is very convenient now to build once and be able to run that code in node, in any browser, and in the spidermonkey and v8 shells. But it might be worth it for code size.

Side note, the reason this has not been done yet is probably that projects like Unity and Epic, and even smaller things like ammo and box2d, don't care much about a few thousand extra lines of code. Their code is far larger anyhow, and their assets 10x larger. But, I fully agree that for smaller programs (without large assets) this would be great to improve.

[abarth]

Thanks for the quick response.

Yes, it would be good to improve this, and contributions would be very welcome of course.

Ok. Let me try to work up a pull request with something simple to get started and we can go from there.

hello_world.cpp uses printf or iostream or such...

Yes, maybe a better place to start is this minimal program:

int main() {
  return 42;
}

And that pulls in our JS filesystem support

Even with -03 and --closure 1, it looks like the minimal program still pulls in MEMFS. (At least createNode still exists in the minified code with the constant 16895, which presumably is 16384 | 511.)

include our Browser object by default

It seems like you should be able to run these small programs in a browser without the Browser object. For example, even the closure-compiled minimal program contains the constant ".ogg", which seems unrelated to the input program. Ideally, this code would be pulled in based on build-time dependencies.

... the reason this has not been done yet is probably that projects like Unity and Epic, and even smaller things like ammo and box2d, don't care much about a few thousand extra lines of code.

Yes, that makes good sense. My use case is a bit different. I'd like to make it easy to mix in small chunks of code written in C++ into another otherwise normal web application.

But, I fully agree that for smaller programs (without large assets) this would be great to improve.

Great! I'm start with a small change to try to get the hang of things. Thanks so much.

[kripken]

I added two options now to incoming, NO_FILESYSTEM and NO_BROWSER. They disable including the filesystem and the browser support components, respectively. Disabling both removes a huge chunk out of hello world,

-O0  373473 => 213990
-O1  353898 => 194788
-O2  149070 => 58016
-O3 --closure 1  83257 => 40811

So, in optimized builds this reduces to around half the original size.

We can still do even better on final 40K here. There are still some runtime features like ccall that hello world doesn't need, and in general lots of exports to the Module object, which we could make optional. And, we build in malloc, which we could give an option to disable.

[kripken]

The ammo.js and box2d.js projects have been updated to use these features. They are a natural fit for projects like them that just do pure computation.

[kripken]

I added a --closure 2 option now as well, which runs closure on asm.js code too. This breaks some asm.js optimizations, but does reduce code size some more. -O3 --closure 2 gives me 37547 bytes, which is 8% less than before.

cc'ing @chadaustin who is a fan of code size reduction tricks

[kripken]

It is also possible to prevent inclusion of libc, from which we normally include things like malloc even for hello world (as the runtime needs it). With

EMCC_FORCE_STDLIBS=fake EMCC_ONLY_FORCED_STDLIBS=1 emcc tests/hello_world.c -O3 --closure 2 -s NO_FILESYSTEM=1 -s NO_BROWSER=1

(kind of hackish - we tell emcc to only use stdlibs we tell it we want ("forced"), then we tell it we don't want any but a "fake" one, so none are included)

With that command I get 18831 bytes, which are 8172 bytes after gzip which is how they would be downloaded over the web. That's small enough that I think it's reasonable to include small emscripten-compiled projects for pure computation on websites (8K is smaller than a typical image, I think).

(Note that it would be hard to turn on those options by default - they all are risky and can break code, if e.g. you actually do need some libc function - but at least they are present.)

[gagern]

I like the fact that you are also thinking about “small emscripten-compiled projects”, since that's my main use case. Anyway, I've just found out that a tiny program using std::shared_ptr will result in 400k of code (100k after compression), with a lot of code from the I/O subsystem and locale management, even though none of this should ever get called, particularly with DISABLE_EXCEPTION_CATCHING=1 so there should be no exception text formatting or similar. The example I have is

#include <memory>
int main(int argc, char** argv) {
  std::shared_ptr<int> sp(new int);
}

em++ -std=c++11 -s DISABLE_EXCEPTION_CATCHING=1 -s NO_FILESYSTEM=1 \
     -s NO_BROWSER=1 -s NO_EXIT_RUNTIME=1 -O3 -o foo.js foo.cc

The way I see it, most of this is just functions which are included since they are placed in virtual function tables. Do we have any chance of detecting and dropping the unneeded ones there? Do you even agree with my assessment? Should I open a new ticket for that aspect?

[kripken]

Eliminating code through function pointers is very hard, but perhaps LLVM can do it with lto, does that help?

[gagern]

Adding --llvm-lto 3 increases the size by 20k. Not a win.

[kripken]

It's likely an issue that we should take upstream then. If we can narrow down what is not being eliminated, and why we think it should be eliminated, at the LLVM IR level in as small a testcase as we can, then we can suggest it to LLVM.

[gagern]

I had a look at the llvm-dis-assembled version of the --save-bc-generated output. Seems most of the stuff in question comes from ios_base::Init::Init() which is used to initialize the global __start_std_streams object. This global initializer is run whenever something links to the libcxx.bc library, e.g. also for this:

#include <algorithm>
int main(int argc, char** argv) {
  int a[] = {3, 5, 2};
  std::sort(a, a + 3);
  return a[0];
}

The way I see it, this ios_base::Init::Init in iostream.cpp is mainly responsible for initializing cin, cout, cerr. So if you were to provide a version of the library where these symbols don't exist, or are initialized lazily, then we might stand a better chance. Of course, once someone starts using an I/O stream, ios_base::init will do a ::new(&__loc_) locale, which leads to pretty much the same initialization. So people would be safe as long as they don't use ios.

---

If we want to take this upstream, here is a small reproducing example:

struct Base { virtual int foo() = 0; };
struct Derived1 : public Base { int foo() { return 15263; } };
Base* b;
struct Init { Init(); } init_guard;
Init::Init() { b = new Derived1; }
int main(int argc, char** argv) { }

Here the implementation Derived1::foo is preserved in the code even though noone ever calls this either directly or indirectly. Looking at the IR, I see _ZTV8Derived1, the virtual function table for Derived1, where this function is entered. The global constructor then stores the address of that list in the memory returned from the new operator. Perhaps one aspect of this problem could be that LLVM sees this new operator just as any other external function. That function returns a pointer, we write to that pointer, and theoretically there could be someone somewhere else outside our control who observes what we wrote and calls the function using that pointer. So the function has to be preserved. I'm just guessing, but this sounds plausible to me.

I guess the kind of dead code elimination I have in mind would require more knowledge about C++. It has to look at the name of that constant and figure out that it's a vtable. It has to identify calls to virtual functions. And – probably hardest of all – it has to work out inheritance to see which virtual function calls could be referring to which virtual functions. That last part sounds really hard if all you have is the LLVM IR.

---

So unless someone comes up with an idea, I consider the approach of a stripped-down or lazily-initializing standard library to be more promising. I just had a look at system_libs.py, and see that you are auto-detecting which libs to use. So if we can get things split up the right way, we might move all the locale and ios and so on stuff into one library, and the rest into a different library, and things will work out automagically.