Skip wasmBinaryFile initialization on pthread workers

[sbc100]

The fact that we were calling locateFile in an attempt to find the wasm binary on each worker was confusing at best. The wasm file is always received via postMessage when running on the worker.

See #21826 and #21827

[kripken]

Code lgtm but I think it's worth seeing why this increases code size. It seems like just moving code around shouldn't cause that, so maybe there is some specific issue that we can improve here.

[sbc100]

Moving this code does seems to have some tiny effects on code size.. some positive but mostly minutely negative. Since this code is simply moved from top level to the inside of a function, with zero changes, I can only assume that is slightly confusing closure compiler.

An alternative to move this code would be to instead wrap it in if (!ENVIRONMENT_IS_PTHREAD && !ENVIRONMETN_IS_WORKER)

[sbc100]

I tried looking at the generated code (after closure compiler was applied) both before and after this change but I'm struggling to come with any rationale for why it might regress.

I took one same regression which is other.test_metadce_mem_O3_standalone_narg which regressed from 4554 to 4580 (24 bytes or 0.5%).

I've attached the result of clang-formatting the resulting JS files.

Can you see where the differences are coming from.
compare.zip

[sbc100]

I did some refactoring, and put this code into a function that can do early returns instead of branches. The code size effects are now almost all wins (especially with gz).

[kripken]

Thanks, after adding some whitespace it is easier to flip back and forth between the files to see the differences,

https://gist.github.com/kripken/286edabc866138d05716c2efbbd1cad4

The main issue (aside from code moving around, which does not affect size) is that in the new code the locateFile usage remains in a function, where it has a return, and there is a call to it. Before it was inlined, saving those bytes.

I see no reason for it not to be inlined in the new code. Perhaps closure is more careful about inlining into nested scopes. Or maybe it is because of the condition right before it - a little hard to see what that was before closure, but maybe you have some idea there.

If not this is probably ok, but it's worth trying a bit to avoid a regression here I think.

[kripken]

Ah, our last two comments raced. Your new code lgtm, and if gzip size is mostly a win then that seems fine.

[sbc100]

Perhaps because createWasm is already quote a large function closure chose not to inline. Or perhaps the inlining rules for top level code are differen to function-scope code?

Anyway, after extracting the function the code size effects seem much better.