Memory usage seems high

[danyill]

I am able to get a great deal of memory usage by doing the following:

paws.zip

1. Open the attached scd file (I think any would do).
2. Open each editor in turn and make one change (any change) to the SCL document where possible.
3. Wait a few seconds between each editor.
4. Wash, rinse and repeat from left to right a few times.
5. Monitor memory in Chrome by hovering over the tab or pressing Shift+Esc
6. Memory usage seems to just go up and eventually the validator starts to complain about a growing buffer.

This is on Windows 10, using Chrome Version 119.0.6045.159 (Official Build) (64-bit)

I shall see if I can reproduce on Linux in some time.

It would be good to know if anyone can reproduce this issue on other browsers or other platforms.

[danyill]

After two rounds with the same base file on Linux I am up to 406 Mb.
With three rounds I am up to 1.4 Gb.

In each round, I open each plugin (from left to right), make one small change or switch views and move to the next plugin.

• Ubuntu 23.10
• Chrome Version 119.0.6045.105 (Official Build) (64-bit)

[JakobVogelsang]

This is pointing towards the schema validator running in an extra worker. I will try and reproduce your findings.

[danyill]

I notice it does not happen if working in a single editor for a long time -- memory usage stays low and almost constant (92.7 Mb).

[JakobVogelsang]

I think I know where it comes from. The validating plugin is doing a parseToString and the schema-validator a parseFromString. These artifacts are not being removed quick enough by the browser and pile up. After a while, the memory usage goes bananas.

You can check by:

1. Disable the auto-validate and make the same changes. The memory consumption should stay the same.
2. Just change one value, say in the Communication back and forth and see how the memory usage is rising.

Btw. I also found that the oscd-open plugin should be improved. When opening new file we are storing those is docs and never remove. When you open 10 different larger files you have easily 4 GB of usage.

[ca-d]

After further testing, @JakobVogelsang and I noticed that a big part of the memory build-up comes just from plugins creating huge DOM trees (e.g. a list of all messages published or subscribed in the entire file) which are not garbage collected quickly enough after switching away from the editor plugin.

This is especially problematic because we currently re-render the full DOM tree every time we switch back to an editor plugin, meaning the plugin might have rendered all its content several times before a garbage collection cycle kicks in.

I propose we fix this by introducing a mechanism for keeping disabled editor plugins around in the background without updating their properties, so that they don't re-render until they become active again, and setting the inert global attribute so that a plugin can react by trimming its DOM tree while unneeded, so as to save on RAM while it's not in use.