Performance problems in large documents

[stippi]

Hi!

According to the hundreds-blocks example, it should be possible to achieve great performance even in huge documents.

For some reason, I am unable to reproduce this with the plate-playground-template project.

This is what I did:

• Cloned the templated project via pnpm.
• Removed a few buttons from the site template and toolbar which should be unrelated.
• Imported a processed version of the script for "American Beauty".
• Created an initialValue for the Editor where every paragraph has a unique id property. See the diff. This looks like absolutely similar to how the initial value is created in the hundreds-blocks example.

Unlike in the hundreds-blocks example, I can barely type in the document. Granted, this editor from the template project has many more plugins installed than the example. In a previous attempt to get started with Slate and Y.js, I observed a very similar problem, and put my efforts on hold. Judging by the React Developer Tools Plugin, the reason for the performance problems at that time was that the entire document was re-rendered at every key-press. This time around, I am unable to obtain any information from the Developer Tools, they never finish processing the profile recording.

It would be so cool if someone could take a look at my project and help me figure this out.

[zbeyens]

I found out withDraggables / withPlaceholders are the bottlenecks. See:

2023-09-22.at.15.02.16.mp4

withPlaceholders being the cause of the profiler issue. withDraggables is not but it seems to slow down the typing.

These HOCs wrap each block so it makes sense. We should optimize these using memo.

[zbeyens]

Mac intel has many perf issues. Above video is recorded with MBP M2 32GB.

[stippi]

Nah... I would turn this around and say that the M2 has one of the fastest single core performance you can get and shouldn't serve as a performance reference. I have some background with laying out and rendering text, and also doing performance optimizations for such large amounts of text. The trick should be to avoid unnecessary calculations for paragraphs that have not changed. My assumption is that the Browser is in principle capable of doing that. Even when typing at the beginning and text is pushed down, that should be possible by applying a constant offset for the net height change of the elements that have changed. My idea for how that should work is that React is good at figuring out what nodes need re-rendering and changing only those in the DOM. The Browser should then used cached layout information for unchanged nodes and whole sub-trees of nodes and should be able to apply those "offset everything by a constant value" type of optimizations.
I will try to gain more insights with the Dev Tools into why it is still a bit laggy on my side.

[zbeyens]

True, I think that the only solution that scales is virtualization, which is not yet supported by slate-react.

[stippi]

By that you mean the React Virtual DOM is not being used by slate-react? If you have links to some discussions that go into more detail, I would be very interested.

As you said, the Dev Tools work again. But I am not sure what conclusions to draw. This is a typical picture:

The props which change on children are either just decorations or decorations and selection. Any idea what is meant by decorations?

[zbeyens]

slate-react uses React.memo to prevent re-rendering unchanged nodes. This is the main reason the performance is good – acceptable. However, it does not scale to 10-100k of blocks since the memoization has an overhead (in your example Children takes already 15.5ms and that number will grow with the number of blocks). I don't think it's due to decorations (and Plate does not use decorations yet).

By virtual I mean using something like this https://tanstack.com/virtual/v3