Add option to inline webworker

[VirtualTim]

Currently when building the USE_PTHREADS Emscripten creates a separate module.worker js file.
This is loaded from module.js like:

var pthreadMainJs = "module.worker.js";
pthreadMainJs = locateFile(pthreadMainJs);
var newWorkers = [];
for (var i = 0; i < numWorkers; ++i) {
  newWorkers.push(new Worker(pthreadMainJs));
}

It is also possible to create an inline webworker, doing something like:

let workerBlob = new Blob(['string_containing_minified_module.worker.js'], type:"application/javascript"});
pthreadMainJs = URL.createObjectURL(workerBlob);
var newWorkers = [];
for (var i = 0; i < numWorkers; ++i) {
  newWorkers.push(new Worker(pthreadMainJs));
}

I imagine that it would be simple enough to minify module.worker.js, then embed that into the main module.js.

I believe that this will speed up loading threads, and should also make webpacking pthreads builds easier/possible.

[kripken]

I'd be interested to know if this helps overall load. It would make the initial download slower, but maybe it's worth it later? The webpack benefits may be worth it, though.

A downside is that this makes debugging harder (can't modify the source) so we have to keep the current approach around, which means this would be a new option.

[VirtualTim]

A downside is that this makes debugging harder (can't modify the source) so we have to keep the current approach around, which means this would be a new option.

Agreed.

It would make the initial download slower

Applying some very basic minification (just whitespace+comments) added 3.13KB to the JS. I'm sure that can be reduced further by smarter minification.

[VirtualTim]

I took a brief look at this, and here's my idea so far:
Settings.js:

//add option:
var INLINE_WEBWORKER = 0;

shared.py:

def generate_inline_webworker(worker_filename):
  webworker = js_optimizer_no_asmjs(worker_filename, return_output=True, extra_info=None, acorn=True)
  return webworker

emcc.py from around here:

emscripten/emcc.py

Line 2374 in 6d297f6

if shared.Settings.USE_PTHREADS:

with ToolchainProfiler.profile_block('memory initializer'):
  if shared.Settings.USE_PTHREADS:
    ...
    with open(worker_output, 'w') as f:
      f.write(shared.read_and_preprocess(shared.path_from_root('src', 'worker.js'), expand_macros=True))
    if shared.Settings.INLINE_WEBWORKER:
      worker = shared.generate_inline_webworker(worker_output)
      # construct js:
      src = ''' //something like
var workerBlob = new Blob(['%(worker)'], type:"application/javascript"});
pthreadMainJs = URL.createObjectURL(workerBlob);
''' % {'worker': worker}
    else:
      # construct js:
      src = '''
var pthreadMainJs = "module.worker.js";
pthreadMainJs = locateFile(pthreadMainJs);
'''
    #insert constructed js (src) into Module
    #I'm not sure how to do this

Does this seem like it's on the right path?
What's the best way to do macro substitution in Module.js?

[kripken]

By macro substitution do you mean the JS preprocessor? There's a helper function read_and_preprocess in shared.py which does that I think.

However I'd recommend measuring this first to see how beneficial it is - I'm not sure it's worth an extra option yet, but I'm curious to see some data.

[VirtualTim]

I guess my motivation was more about making pthreads builds easier/possible to webpack.
I'll investigate more first if it fixes the issue, and then also do some profiling.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[jeffRTC]

@VirtualTim

I badly need this for a restricted environment where external files are not allowed. It's like the -s SINGLE_FILE=1 option.

[jeffRTC]

@VirtualTim

I just created a NodeJS script to inline the worker and it works, but would be better to add it to compiler it-self.

const fs = require('fs');
const args = process.argv;

function escapeIt(string) {
    return string.replace(/[\`]/g, '\\`');
}

// MyModule
let moduleName = args[2];

// C:/runtime.js
let runtimeScriptFilePath = args[3];
// C:/runtime.worker.js
let workerScriptFilePath = args[4];

let runtimeScript = fs.readFileSync(runtimeScriptFilePath, "utf8");
let workerScript = fs.readFileSync(workerScriptFilePath, "utf8");

let target = `locateFile("${moduleName}.worker.js")`;
let replace = `URL.createObjectURL(new Blob([\`${escapeIt(workerScript)}\`], { type: "application/javascript" }))`;

let result = runtimeScript.replace(target, replace);

fs.writeFileSync(runtimeScriptFilePath, result);

[VirtualTim]

I'm glad you've got something working.
Personally I've long abandoned that idea, it didn't help with my bundling issue, and made start-up significantly slower.

I know of one other project that's doing something similar, so I still think there's value of adding this to Emscripten. I'm just not going to be the one to do it.

[RReverser]

Cross-commenting here too - rather than using Blobs or inlining worker JS as string in other ways, I think a better solution is to actually inline Worker's code as normal JS into the main one in SINGLE_FILE mode.

Then, it's possible to detect whether the code is running as main JS or as worker JS, and branch correspondingly. Such condition can be a special GET param (then Worker could be created as new Worker('...?emscripten-worker')) or a global name (new Worker('...', { name: 'emscripten-worker' })) or something else in similar spirit. (Note: just checking ENVIRONMENT_IS_WORKER is not enough, because main JS might be used in a Worker too).

[sbc100]

Sounds good to me. Any reason no to do make this the default? It would simplify deployments to not need the extra file.

The only down I can think of is the marginal increase in JS codesize used on the main thread... but that is marginal and fixed and seem worth it given the amount if simplification we would get. It also get confused about how the main js file is loaded into the pthread workers (I think we use eval under node.. which is kind of scary)

[sbc100]

I mean any reason not to make this the only way to do things?

[RReverser]

I think we use eval under node

With ES6 we should just use import everywhere, which is fine. Node.js output being incompatible with ES6 mode is a separate issue 😀

I mean any reason not to make this the only way to do things?

Mostly the size increase you noted, which, in turn, means slower download of the initial JS. But I guess you're right that it doesn't matter too much, especially since the application is likely to need that worker JS before the app start anyway (for the PTHREAD_POOL mode).

[VirtualTim]

I mean any reason not to make this the only way to do things?

I think this will make the threads more heavy-weight. I suspect that this will also have a negative effect on JS optimisation, but actual profiling will be needed to know if it is worth worrying about.

[sbc100]

I mean any reason not to make this the only way to do things?

I think this will make the threads more heavy-weight. I suspect that this will also have a negative effect on JS optimisation, but actual profiling will be needed to know if it is worth worrying about.

What makes you say it will make threads more heavy-weight? IIUC it will make the amount of code loaded onto a worker strictly less since since the code needed to load the main js file inside the worker.js file (the whole eval thing) can be completely removed.

[VirtualTim]

Back when I was experimenting with getting SINGLE_FILE working with workers ~2 years ago I found it drastically increased startup time. Things have obviously changes since then, and @RReverser's approach is likely to perform differently.

I can't seem to find the results of the profiling I previously did, but I did have a hard drive die sine then, so it may be lost.
I think the issue I had was that inlining the webworker resulted in the browser having to load the whole WASM+JS file in each webworker on initialisation, which was adding a few seconds per thread. But that years years ago, and I can't find my notes on this, so I will defer to any more recent profiling.

[RReverser]

Yeah it does sound like it's the added overhead from using Blobs with JS code as strings, which behave quite differently than normal URLs in terms of caching and sharing resources. I think Worker logic inlined in the main file should behave much better in this regard.

[merceyz]

Ran into this in Yarn as well, in our case the CLI is bundled as a single JS file so we can't have it try to load itself nor any other file. The only option for us would be to embed the worker as a string and pass it directly to the Worker constructor either using a data URL or the eval flag.

If the output was Webpack friendly we could handle this on our end

Build script: https://github.com/yarnpkg/berry/blob/28ec64eb89258e110d98ccc55cfdd926fb7413d8/packages/yarnpkg-libzip/artifacts/build.sh#L96-L112

[Username404-59]

It would be a good idea to implement this with the SINGLE_FILE setting instead of creating a new one, else... well it won't produce a single file ¯\_(ツ)_/¯

[bamtheboozle]

has this gotten anywhere or is it dead?

[msqr1]

After 4 years lol. Would you do this for wasm workers, too? @sbc100

[RReverser]

@sbc100 Nice, great job!