about:memory shows 5 strings with total length around 90-100k and thus taking around 200k of memory (yay ucs2 + js overhead, I guess).

This is in addition to the actual interpreted/compiled representations.

We should try to avoid this. It's probably a consequence of the use of require.js - perhaps now we can "just" use es6 modules or some other, better mechanism.

It might also be the DOM holding one copy of the string and JS holding another copy.

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #1)

It might also be the DOM holding one copy of the string and JS holding another copy.

Sorry, what exactly do you mean? Workers don't have a DOM, right?

They don't have access to the document but they have access to some DOM APIs.

Here, it's XHR used in a worker.

Marking as P3 because it seems only related to memory usage. However, if someone proposes a solution that would also improve the load times for OS.File, we would probably bump the priority.

I thought that memory usage was back to being a priority?

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #5)

I thought that memory usage was back to being a priority?

We're focused on startup time and mainthread IO for the moment.

This will be solved when we remove OS.File

OS.File is being removed.