Repository navigation
Memory usage seems high #4
Description
I am able to get a great deal of memory usage by doing the following:
- Open the attached scd file (I think any would do).
- Open each editor in turn and make one change (any change) to the SCL document where possible.
- Wait a few seconds between each editor.
- Wash, rinse and repeat from left to right a few times.
- Monitor memory in Chrome by hovering over the tab or pressing Shift+Esc
- 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.
Activity
danyill commentedon Nov 17, 2023
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.
JakobVogelsang commentedon Nov 17, 2023
This is pointing towards the schema validator running in an extra worker. I will try and reproduce your findings.
danyill commentedon Nov 18, 2023
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 commentedon Nov 18, 2023
I think I know where it comes from. The
validatingplugin is doing aparseToStringand theschema-validatoraparseFromString. 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:
auto-validateand make the same changes. The memory consumption should stay the same.Communicationback and forth and see how the memory usage is rising.Btw. I also found that the
oscd-openplugin should be improved. When opening new file we are storing those isdocsand never remove. When you open 10 different larger files you have easily 4 GB of usage.ca-d commentedon Mar 19, 2024
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
inertglobal 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.