Compiler information extraction significantly slower compared to vanilla Clang

[boris-kolpackov]

Extracting some basic information (version, target, header search paths) from emcc is significantly slower compared to vanilla Clang. Compare:

$ time { clang++ --version; clang++ -dumpmachine; clang++ -v -x c++ -E - </dev/null; }
real    0m0.029s

$ time { emcc --version; emcc -dumpmachine; emcc -v -x c++ -E - </dev/null; }
real    0m0.266s

Some build systems (e.g., build2) extract this information on the fly (in order to implement high-fidelity change detection) and the slowdown is noticeable. I wonder if anything can done about this?

[sbc100]

There may be some small improvements we can make but I think -dumpmachine exits very early on so I imagine most of the time is explained the python startup time and processing emscripten's config.

Can you explain what you mean by "extract this information on the fly"? How frequently is this being being run exactly? Presumably one per build would be totally fine. Are we talking once per build edge of something like that?

[kripken]

Do you think in the long term moving to a sysroot approach could solve this, @sbc100 ?

In the short term you can use emcc --cflags to get the flags we'd pass to clang, and call clang directly, skipping Python. But you do need to be careful to pass the right ones.

[sbc100]

It could help to invoke clang directly but the build system would still need to invoke emcc at least once to get the right cflags, and the only way to make that fast would be to cache the result of emcc --flags .. which I think would kind of undermine the whole point this bug report which seems to be for a build systems that don't want to cache this kind of information but instead ask for it constantly from the compiler.

[boris-kolpackov]

Can you explain what you mean by "extract this information on the fly"? How frequently is this being being run exactly? Presumably one per build would be totally fine. Are we talking once per build edge of something like that?

Yes, this is done once per build. However, we have to make quite a few invocations to get all the information (which by itself is unfortunate). Here are all the commands that we end up running for Emscripten (and other Clang-based compilers):

em++ -v
em++ -dumpmachine
em++ -E -                        # for runtime detection (libgcc, compiler-rt, etc)
em++ -E -                        # for standard library detection (libc++, libstdc++, etc)
em++ -print-search-dirs          # library search paths
em++ -v -E -                     # header search paths

If the code uses any C compilation, then it's another full set of these for emcc. And if C++ (or C) use different standards, then we have to re-run the last two since different standards can plausibly result in different search paths. So for a real-world project we are looking at 15-20 invocations, which in case of Emscripten translate to a couple of seconds delay.

[...] build systems that don't want to cache this kind of information but instead ask for it constantly from the compiler

Right, if we cache it across builds, then that means we need a precise mechanism for invalidating this information, which itself is a big can of worms (we will still need at least one execution to derive the compiler checksum).

[sbc100]

Is it really ~2 second difference for the null build between native clang and emcc? Do you have way of measuring the cost of the null build?

There may be some low hanging fruit here (perhaps once of those commands is doing something pathological) but it could also be that this is just the cost of starting up python and configuring emcc N times, in which case there will be limits to what we can do. Patches/ideas welcome though.

[boris-kolpackov]

Is it really ~2 second difference for the null build between native clang and emcc? Do you have way of measuring the cost of the null build?

Yes, vanilla Clang:

$ time b noop

real    0m0.267s
user    0m0.147s
sys     0m0.123s

Emscripten:

$ time b noop

real    0m1.458s
user    0m1.190s
sys     0m0.281s

This is for a build configuration that contains a bunch of packages I pulled for testing (some are C++ and some are C):

libexpat-2.2.9
libhello-1.0.0+6
libpdjson-0.1.0
libsqlite3-3.27.2+1
sqlite3-3.27.2+1
libstud-json-0.1.0
libz-1.2.1100+1
pugixml-1.10.0+2

it could also be that this is just the cost of starting up python and configuring emcc

In a sense, this is a more general problem, consider:

$ time clang++ -x c++ -E - -o - </dev/null >/dev/null
real    0m0.013s

$ time em++ -x c++ -E - -o - </dev/null >/dev/null
real    0m0.081s

Which means that for every compilation Emscripten adds a ~70ms overhead. For perspective, it takes that long to compile (with vanilla Clang) a C translation unit that implements a conforming JSON parser (pdjson.c).

BTW, all these tests were performed on a decent Linux workstation (Xeon E-2288G, Samsung 970 Pro).

[sbc100]

Indeed this seems to be the fixed overhead of emscripten over of clang. There may be some low hanging fruit if anyone wants to benchmark the emscripten started. I imagine it falls into 3 categories:

1. cost of starting python
2. cost of configuration done when shared.py is imported.
3. cost of parsing command line arguments before calling clang.

It could be possible to make some progress on (2) and (3) but its worth measuring first. Its unlikely that the core team will have time to work on such optimizations in the near future because we have a lot of other challenges. If you would like work on this we could welcome improvements. Perhaps a good place to start is in measuring benchmarking so that we can prevent regressions in this area.