Ckeditor5: Memory leaks - they're back

[jodator]

📝 Provide detailed reproduction steps (if any)

1. Create / destroy editor

✔️ Expected result

No editor in the memory.

❌ Actual result

There is an editor left in the memory

📃 Other details

Performance time line:

There's ClassicEditor in the memory:

And some detached event listeners:

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[andycrulez]

👍
this one is quite crucial to me. I'm using the CKEditor5 with Angular on the production (inline editor) with multiple instances on multiple pages. I can easy reach 2GB of memory :)

[martijnpieters]

Same problem over here. Next week we're going to try to make a dynamic Multi-root Editor, to see if we get an acceptable performance.

[martijnpieters]

Been there, done that. Under 75MB for a tab with tens of editable fields.

[QuentinLeGoff]

Hello,
I'm facing the same problem with DecoupledEditor and collaboration feature.

Without collaboration feature, GC seems to remove instances but when I use the RealTimeCollaborativeEditing, objects accumulates on JS VM.

And each time I load new document (destroy then create to load new document in CKEditor Cloud Services), it take more time than before to create editor.

[jodator]

I did a quick scan today of the state of things and it _looks_ like some of the memory leaks sources were removed from the time I've reported that.

As for the integrations I didn't check but I would advise anyone to check if memory leaks comes from the editor itself or not. Any non-destroyed listener which touches editor instance could prevent freeing memory.

edit: Also logging editor to the console and not clearing the console will also hold that editor instance in memory after the editor was destroyed.

[meddiecap]

I don't know if I need to drop this here, but I used the (new?) builder at https://ckeditor.com/ckeditor-5/online-builder/
If it's of any use: _"Build id: 32ppao8vorw3-2dtu63mfs6mp"_
(34 plugins selected)

I've attached a super simple html page that managed to go to 40mb in JS memory on the first load and each page refresh easily adds 20mb, and it never goes down.

testing.txt

Is there any way in JS to manually empty the memory or something like that?

[jodator]

Hi @meddiecap! How did you test the memory consumption? 

I did a quick test with a similar setup and the results for page refreshing are as follow:

1. The "JavaScript VM Instance" memory utilization goes up and down, randomly. In my case in the 50 - 250 MB range.
2. The "Heap Snapshot" (used memory per page/app) is in the 57 - 63 MB range. 

If the memory goes up/down on the page refresh it's up to the browser what it keeps in the memory and we can't control that. A full running editor will consume this much memory unfortunately.

So this is how Chrome utilizes memory on page refresh and we can't control that. A memory leak would occur if you'd

1. Crate an editor.
2. Use the editor.
3. Destroy the editor (editor.destroy())

And the memory after step 3 would be the same or significantly bigger than the memory after step 2. You can observe this below:

[meddiecap]

Hey @jodator , thank you for your extensive explanation.

I test the memory consumption by simply refreshing the page.

Your first GIF shows me that you refresh the page a few times and then take a heap snapshot.
The results differ in that your snapshots seem to grow in a much slower pace than mine.
(Apologies for the low quality. What do you use for screen capturing?)

Your second GIF gives me the impression that it is best to destroy all instances of ckeditor when, and just before, a user wants to leave or reload the page. (Or when new content is loaded via AJAX which will replace the ckeditor with a new one, which I also intend to do.)

I tried just that and the snapshots do grow less, but still around 15mb per page reload:

    let allEditors = document.querySelectorAll('.ckeditor');
    let editorsLength = allEditors.length;

    window.editors = [];

    for (let i = 0; i < editorsLength; ++i) {
        ClassicEditor.create(allEditors[i], defaultConfig ).then(editor => {
            window.editors.push(editor);
        });
    }

    window.onbeforeunload = function() {

        for (let i = 0; i < window.editors.length; ++i) {
            window.editors[i].destroy();
        }
    };

[jodator]

window.editors = [];

this is preventing memory from being collected by the Garbage Collector during a page life cycle.

Your second GIF gives me the impression that it is best to destroy all instances of ckeditor when, and just before, a user wants to leave or reload the page.

The results differ in that your snapshots seem to grow in a much slower pace than mine.

If you refresh the web page you get a clean state (so the previous JavaScript objects are removed). There is no need, at least to my knowledge, to clean the editors if a user simply leaves a page. If you plan to reload the editor on AJAX calls then using editor.destroy() is a way to go. But remember to check if the editor instance is not held somewhere (like in window.editors[]).

The +20 MB on every page refresh is very strange. On quick research, I've found one bug in Chrome (which might be unrelated to your case) so it _could_ be possible that some other code is still retaining objects.

However, the results you present in the GIF are curious - it looks like something _might_ retain objects. The best way to verify memory leaks is to run the browser without any addons enabled:

google-chrome \
    --disable-extensions \
    --disable-plugins \
    --incognito

What do you use for screen capturing?)

You can compare snapshots between each other and inspect what happens there. But it might require some longer digging and staring into the Reatiners list :/  More on this here (and here :wink:)

I've used peek - it's Linux only tool.

[meddiecap]

I watched the youtube video, very interesting.

For now, when I leave the page, I loop over the editors and .destroy() them.
When I load new content using AJAX that needs to initialize an editor, I destroy the old ones first.

Although I still get the memory spikes I mentioned before, it also seems to be related to the DevTools. I don't know well how to read all the data but with every page refresh it looked like the snapshot tool stored and extra 8 "ck" object / classes.

Ckeditor was giving me console warning about missing toolbar stuff and fixing that also had some impact.

When I don't use DevTools, the memory will go back down to much more acceptable levels after around 10 seconds.
When I keep it open, the memory stays up.

I learned a lot today
Many thanks @jodator