Import a module in a PromiseWorker

Add-ons Development
#1

Hi *,

I’d like to know how to import modules within a PromiseWorker.

In my addon, the files are organized like this:

main.js
promise_worker.js
/data
/engine
    common.js
    module1.js
    module2.js
    ...
    /subengine
         subengine.js
         ...

I have no issue when I call the modules from main.js. Using require is enough:

require('./engine/module1.js');
require('./engine/subengine/subengine.js');

But it doesn’t work if I call these modules or submodules from the PromiseWorker module.

#2

The problem here is, that a PromiseWorker doesn’t create a commonJS environment, and instead creates a ChromeWorker context. See https://developer.mozilla.org/en-US/docs/Web/API/ChromeWorker and especially https://developer.mozilla.org/en-US/docs/Mozilla/ChromeWorkers/Chrome_Worker_Modules for more info. So they are pretty similar to web workers, just that you can load some existing files.

#3

Thanks.

#4

doing importScript(path_to_file_here) is the equivalent of <script src="path_to_file_here"></script>

There is also a require thing you can import. I don’t know that works though:

importScripts("resource://gre/modules/workers/require.js");
let PromiseWorker = require("resource://gre/modules/workers/PromiseWorker.js");
#5

Yeah, it works. It’s not a full-featured CommonJS module loader, but it’s a start.

1 Like
#6

Yes, this is written in the documentation about PromiseWorkers.

To import what I wanted, I just had to write in a file called “chrome.manifest”:

resource engine ./engine/

Then I could import my modules with commands like:

require('resource://engine/module1.js');
require('resource://engine/subengine/subengine.js');
1 Like
#7

Ah interesting. Do you know the difference from this and importScripts?

Edit:
Ah i see Yorics answer, it’s the beginnings of a CommonJS module loader.

#8

Using PromiseWorker was an excellent choice. My script is approximately 20 times faster while running in a separate thread… In the main thread, my script needs ~250 s to perform all the tests. In a separate thread, it takes 12-13 s.

That’s a huge difference. I can’t stop wondering why it’s so slow in the main thread.

1 Like
#9

Very cool. Probably because there’s nothing else that thread. So it’s not waiting on other operations to finish before getting to your operations.

Speed isn’t the main reason for the thread. It’s mostly for keeping the main thread running smooth. As main thread is GUI. So in case you get slower speeds don’t worry and revert back to main thread. There is still a usability gain. :slightly_smiling:

#10

I didn’t use a PromiseWorker with the expectation it might go faster. The documentation says nothing about that. I wanted to prevent Firefox from freezing.

Yes. That’s what we can guess…

But…

These tests just perform data analysis. I can launch them when there is no interaction with the UI, no web page loaded, when Firefox is just empty and does nothing else… and it’s still 20 times slower than with a separate thread. That’s why it’s so surprising.

1 Like