WebAssembly is out of memory with multiple modules on one page

[WolfgangDrescher]

I have a SPA (using Vue.js, so no page loads where the VerovioModule will reset) in which I use verovio/esm to display multiple scores on one page. Verovio is running in a web worker. I have an overview page with currently ~25 score segments and verovio instances. Although we have a comment in the verovio source code that "only one instance can be created for now" it is possible to still have multiple instances. However, if I filter the scores several times so that new components with verovio instances are removed and added again, at some point I get the following error.

verovio-module-hum.js:9 Uncaught (in promise) RuntimeError: Aborted(RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance). Build with -sASSERTIONS for more info.
    at abort (verovio-module-hum.js:9:8239)
    at verovio-module-hum.js:9:10599791

My setup:

• a new worker is created for every single score
• in the worker a new VerovioModule is created with createVerovioModule() imported from verovio/wasm-hum.
• once a score/component is not needed anymore it gets destroyed with onUnmounted(() => toolkit.destroy())

I am not sure whether my setup is not optimal, the verovio toolkit destroy is not working as expected, or this feature needs some improvements in verovio.

Is it wrong to create a new module for each score instance? When I try to use a single module for all instances then I get back wrong scores because the module is not aware of the current state passed with toolkit.loadData and toolkit.setOptions, etc.

Reproduction

I have setup a reproduction repository without web worker: https://github.com/WolfgangDrescher/verovio-out-of-memory
You can also check this directly on StackBlitz: https://stackblitz.com/github/WolfgangDrescher/verovio-out-of-memory?file=src/App.vue

Click "Load 10 scores" button until you get the error WebAssembly.instantiate(): Out of memory in the console. This should happen at the range 80-90.

[ahankinson]

Are you creating a new toolkit for every score?

The best way, if you're using a web worker, is to treat the web worker as a "server" that hosts a single toolkit. Then it's up to you to clear / reinitialize the Verovio state with every score load. You send a message to the "server" with a score data to render, and it responds with some SVG.

[WolfgangDrescher]

Are you creating a new toolkit for every score?

Yes I have a new toolkit instance with a new module for every score (example component).

For now I'm only reloading the score with renderToSVG when I need a new page or a different scaling, etc. So best practice would be to use a single toolkit/module and handle the states myself and then always chain these methods passing the current state of the options, page number and data (at least for my simple use case):

1. loadData
2. setOptions
3. renderToSVG

Are there no performance issues if the score has to reload the score with loadData before each renderToSVG?

[ahankinson]

Are there no performance issues if the score has to reload the score with loadData before each renderToSVG?

No, in fact you might see a performance boost, since (I think) the act of spooling up a new toolkit is what actually takes time.

[WolfgangDrescher]

Not for single score usage I guess. But since I need multiple instances I will try this. So yes setting up all the modules took quite a while for 25 examples. Thank you again.

[craigsapp]

Each instance has a fixed (or at least minimum) size of 250 MB. So 25 instances would be 6.25 GB, which is why you are running out of memory. If the 25 segments are short, then you should definitely use the method that @ahankinson mentions: one instance that produces 25 segments.

[lpugin]

Is it wrong to create a new module for each score instance? When I try to use a single module for all instances then I get back wrong scores because the module is not aware of the current state passed with toolkit.loadData and toolkit.setOptions, etc.

You probably avoid that by using renderData, which does option setting, loading and rendering in one step. See https://book.verovio.org/toolkit-reference/toolkit-methods.html#renderdata
A limitation is that it will only render the first page.

[WolfgangDrescher]

I implemented this in my project. It's not perfect but it works for now and is a lot faster than creating a new module for every toolkit. I store multiple toolkits within the worker. Here is a link to my solution for future reference: https://github.com/WolfgangDrescher/vue-verovio-canvas/blob/master/src/functions/verovio-worker.js (commit 0f2fc2d).

One little caveat is that the toolkit won't get destroyed when waiting for a message from the worker. So eventually it will run out of memory once this happens approx. 100 times.

[ahankinson]

I just quickly extracted some code from a project I'm working on. It's TypeScript, but should be more-or-less readable as JS.

https://gist.github.com/ahankinson/c655dd35ed455c2b0139f3bd9f60e36c

Basically it's a WebWorker, but uses a Proxy object that makes the worker "appear" as an async call to the worker, so you can just to await verovio.someMethod() and it should work.

Most of it was originally written as JS by @lpugin and then adapted a bit by me.

[WolfgangDrescher]

Thank you, this looks similar to my approach in https://github.com/WolfgangDrescher/verovio-worker from some years ago.

Are you using a JS framework? In my case the tricky part was that I wanted to have a component that I can use multiple times in my project but also use multiple scores on the same page. My solution was to use a state manager to get access to the worker from anywhere in the application (pinia in my case).

Here is my solution. Maybe it's useful for someone. I'm using Vue.js but it should be possible to refactor this for React, Angular, etc.

workers/verovio.js:

import createVerovioModule from 'verovio/wasm-hum';
import { VerovioToolkit, enableLog, LOG_OFF as logLevel } from 'verovio/esm';
import { createVerovioWorker } from 'vue-verovio-canvas';

createVerovioWorker(createVerovioModule, VerovioToolkit, enableLog, logLevel);

composables/verovio-worker.js:

import { defineStore } from 'pinia';
import createVerovioWorker from '../workers/verovio.js?worker';

export const useVerovioWorker = defineStore('verovio_worker', {
    state: () => {
        return {
            verovioWorker: createVerovioWorker(),
        };
    },
});

components/VerovioScore.vue:

<script setup>
import 'vue-verovio-canvas/style.css';
import { VerovioCanvas, createWorkerVerovioToolkit } from 'vue-verovio-canvas';

const { verovioWorker } = useVerovioWorker();
const toolkit = createWorkerVerovioToolkit(verovioWorker);
</script>

<template>
    <VerovioCanvas v-bind="{ ...$attrs, ...$props }" :toolkit="toolkit" />
</template>

Also have a look at https://github.com/WolfgangDrescher/vue-verovio-canvas

[WolfgangDrescher]

Actually I am thinking about adding an integration for web workers to the verovio npm package using the ESM module. With this bundlers like vite and webpack can easily create the worker with a helper function. It was not possible for quite a while because emscripten was not ready for ESM support. Recently there was some progress and emscripten-core/emscripten#11792 was implemented in emscripten-core/emscripten#17915. So since emscripten v3.1.27 it should be possible to use -sEXPORT_ES6.

I will probably open a new discussion or PR for this when I find some time to test this. But I'm not sure if we can find a solution for this that is generic enough for all the different use cases.

[ahankinson]

TBH, I usually find JavaScript frameworks more trouble than they're worth, and avoid them like the plague. :-D

[WolfgangDrescher]

Is the parallel use of multiple toolkit/module instance at once something we could improve in verovio, or is this one of the limitations we have because of emscripten?

[lpugin]

It think we can improve it. It would be necessary to see how we can control the memory allocation. For now it is essentially designed to run one or maybe a couple of toolkit instances, but not a high number. For this to work, then the allocation should not be 250 MB / toolkit, but probably something more like 50, or maybe even less.

In fact, the memory allocation is per module, not per toolkit. So it should be possible to refactor your worker and create multiple toolkit instances within one module.

[lpugin]

FYI, I tried to create multiple toolkits within one module and to load a one page file. All the memory is used with about 120 toolkits.