wasm-emscripten-finalize speed

72 views
Skip to first unread message

Patrik Weiskircher

unread,
Jan 22, 2020, 2:31:23 PM1/22/20
to emscripten-discuss
Hi!

I'm working at PSPDFKit trying to upgrade our Web viewer from Emscripten version 1.38.31 to 1.39.6.
I got everything working so far, I'm just having a little trouble with the linking speed. Everything goes fine and quick
enough until we hit linking the library - specifically the `wasm-emscripten-finalize` step.

The exact command line is this:
> /opt/emsdk/upstream/bin/wasm-emscripten-finalize --detect-features --global-base=1024 --check-stack-overflow \
> /tmp/emscripten_temp_rjgvGG/pspdfkit.wasm.wasm -o /tmp/emscripten_temp_rjgvGG/pspdfkit.wasm.wasm.o.wasm

This takes around 15 minutes. While this isn't a deal breaker, it does make our CI quite slow and keeps agents occupied
longer than necessary. It'll also not be great when we have to debug a problem on Emscripten in the future.

I looked around on the GitHub issue board and also on the mailing list but I couldn't find any information about this. I
understand we have quite a big code base and things will take some time - I'm just wondering if anyone has any tips
on how I could debug what *exactly* takes this long or how to make this any quicker?

Thanks so much!
Patrik


Alon Zakai

unread,
Jan 22, 2020, 3:52:56 PM1/22/20
to emscripte...@googlegroups.com
Oh, wow, it shouldn't be anything like that...

If you built binaryen by yourself, I'd make sure that's not a debug build. Another thing is to check you don't set BINARYEN_CORES=1 in the environment (which would prevent an almost linear speedup with more cores). And in a very big project perhaps it takes enough memory to cause swapping, so checking peak memory usage etc. might be interesting.

If those aren't it, I'd run it in a profiler to see what's taking so long. If you can share the file I can take a look too.

- Alon




--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/cca83aa0-c022-4a94-8cc6-42063b5ccebc%40googlegroups.com.

Sam Clegg

unread,
Jan 22, 2020, 3:59:59 PM1/22/20
to emscripte...@googlegroups.com
I recently tracing channels to binaryen and some minimal tracing to `wasm-emscripten-finalize`.   You might be able to get some clues from adding `--debug=emscripten` to the command line.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpREWRPRu1M%3DEx2t%2BQXkt7pQ64sgFC%2BaGU6h_H5vbX9ocA%40mail.gmail.com.

Patrik Weiskircher

unread,
Jan 22, 2020, 4:23:31 PM1/22/20
to emscripte...@googlegroups.com

If you built binaryen by yourself, I'd make sure that's not a debug build.

Simply did `emsdk install latest` and nothing is built by myself.

Another thing is to check you don't set BINARYEN_CORES=1 in the environment (which would prevent an almost linear speedup with more cores).

Don't think this is a problem here. I see `top` report 800% CPU use so it's definitely using all Cores.

And in a very big project perhaps it takes enough memory to cause swapping, so checking peak memory usage etc. might be interesting.

It's only at 15.8% memory usage.

If those aren't it, I'd run it in a profiler to see what's taking so long. If you can share the file I can take a look too.

I honestly don't know enough about what format the file is in to make a good decision here. The code that I am compiling is proprietary but I feel like at that stage it's just one big object file without any source? As long as we're not leaking source code I'm very happy to share the file :)

I recently tracing channels to binaryen and some minimal tracing to `wasm-emscripten-finalize`.   You might be able to get some clues from adding `--debug=emscripten` to the command line.

I just added this! Here is the result:

[PassRunner] running passes...
[PassRunner]   running pass: legalize-js-interface... 863.403 seconds.
[PassRunner]   (validating)
[PassRunner] passes took 863.403 seconds.
[PassRunner] (final validation)


You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/Tj7C5Ij4sx8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28KeT9VfF45%3D%3DAEmVSML79uB9L%2B%2BWJV6EG6%3DL3NoGtvjg%40mail.gmail.com.

Alon Zakai

unread,
Jan 22, 2020, 4:50:56 PM1/22/20
to emscripte...@googlegroups.com
> The code that I am compiling is proprietary but I feel like at that stage it's just one big object file without any source?

Yeah, if you look at the input to wasm-emscripten-finalize, it's very close to the final wasm binary you'd ship on the web. So it's all compiled into wasm binary code at that point.

One possible difference is this binary might contain function names, which might be stripped out by emcc later depending on the options. You might also want to take a look at the binary yourself to see if there's anything that looks like you can't share it, just to be sure.

> [PassRunner]   running pass: legalize-js-interface... 863.403 seconds.

I wonder if that's an error in the measurement, otherwise, that's very surprising, I don't remember any non-linear algorithms there... anyhow, if you share the binary I can investigate, should be easy to narrow something that noticeable down ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CANMzfzh6oQ6656xYf-C7T7eo5Es57TsnkkrNzFiJx64%3Dcx4whA%40mail.gmail.com.

Alon Zakai

unread,
Jan 22, 2020, 4:51:54 PM1/22/20
to emscripte...@googlegroups.com
Oh, the wasm-emscripten-finalize binary might also contain DWARF debug info, which is related to source code. But if you didn't compile source files with -g that that won't be there.

Patrik Weiskircher

unread,
Jan 22, 2020, 5:00:31 PM1/22/20
to emscripte...@googlegroups.com
> [PassRunner]   running pass: legalize-js-interface... 863.403 seconds.
> I wonder if that's an error in the measurement, otherwise, that's very surprising, I don't remember any non-linear algorithms there...

It is NOT an error in measurement, it really takes that long. I've been profiling using Instruments on my Mac and from what I see most of the time is spent here:


Specifically modifying the `unordered_map`.

If I understand the code correctly, this basically means we have a *ton* of functions that we're trying to export and therefor have to "legalize"? Is it possible that we just have our project a little misconfigured and instead of only exporting methods with Embind everything is exported? I couldn't explain why the unordered_map would be used for 15 minutes(!) otherwise.

anyhow, if you share the binary I can investigate, should be easy to narrow something that noticeable down ;)

Would you mind if I send it to you personally instead of to the mailing list? If you think it is even necessary anymore seeing the above statement.



Alon Zakai

unread,
Jan 22, 2020, 5:56:51 PM1/22/20
to emscripte...@googlegroups.com
On Wed, Jan 22, 2020 at 2:00 PM Patrik Weiskircher <pat...@pspdfkit.com> wrote:
> [PassRunner]   running pass: legalize-js-interface... 863.403 seconds.
> I wonder if that's an error in the measurement, otherwise, that's very surprising, I don't remember any non-linear algorithms there...

It is NOT an error in measurement, it really takes that long. I've been profiling using Instruments on my Mac and from what I see most of the time is spent here:


Specifically modifying the `unordered_map`.

If I understand the code correctly, this basically means we have a *ton* of functions that we're trying to export and therefor have to "legalize"? Is it possible that we just have our project a little misconfigured and instead of only exporting methods with Embind everything is exported? I couldn't explain why the unordered_map would be used for 15 minutes(!) otherwise.

anyhow, if you share the binary I can investigate, should be easy to narrow something that noticeable down ;)

Would you mind if I send it to you personally instead of to the mailing list? If you think it is even necessary anymore seeing the above statement.


Feel free to send it to me personally, yeah. I still need to figure out why that code is taking nonlinear time - that should just be doing a linear scan over the wasm module...

Is this built with MAIN_MODULE perhaps? That would increase the # of exports. Still, no number can explain that slowdown, so it's still a mystery to me.

Patrik Weiskircher

unread,
Jan 22, 2020, 6:46:12 PM1/22/20
to emscripte...@googlegroups.com
Just sent the file. Thank you for looking into this, Alon!

On Jan 22, 2020, at 5:56 PM, Alon Zakai <alon...@gmail.com> wrote:



Alon Zakai

unread,
Jan 22, 2020, 7:48:26 PM1/22/20
to emscripte...@googlegroups.com
Thanks, turns out this was indeed doing unnecessary quadratic work. Fix in


It takes 5 seconds on my laptop now.

- Alon


To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/8109E6E4-DBDE-420E-B3A8-276FD3DE8A2A%40pspdfkit.com.
Reply all
Reply to author
Forward
0 new messages