Slow Pasting of Large Text Content in Slate.js

[electroluxcode]

Compared to Tiptap, Slate seems to perform poorly when pasting large amounts of data.
I generated test data using:

let text = [];
for (let i = 0; i < 10000; i++) {
  text.push(`${i} this is a test demo. \n`);
}
let res = text.join('');
console.log(res);

Then I pasted the generated text into Slate (https://www.slatejs.org/examples/plaintext) and Tiptap (https://tiptap.dev/docs/examples/basics/default-text-editor) respectively.
Slate took about 7 seconds to parse the content, while Tiptap only took 1 second.

Are there any ways to optimize this?

[12joan]

That's quite a big difference. I'm not sure how Tiptap handles pasting internally, but here's how Slate handles this case: editor.insertTextData splits the text into lines and alternates calling editor.insertText(line) and Transforms.splitNodes(editor, { always: true }).

88% of the total time in insertData is spent normalizing the editor after each split and insertion. It's possible that deferring normalizations until the end of insertData will improve things a little.

Another interesting result is that around 50% of the time spent in insertData is spent inside isEditor, a utility that's supposed to check if a given object is a Slate editor. Specifically, most of this time is spent inside isOperationList, which checks if editor.operations is a correctly formed list of operations.

Since every operation needs to be checked, and the number of operations increases with each new line of text that has been inserted, this causes the overall time spent in isOperationList to have time complexity O(n^2).

I don't see why we should bother validating the exact structure of editor.operations just to determine that an object is a genuine editor. Checking for a property called operations should be more than sufficient.

@electroluxcode Do you want to try experimenting with optimising this?

[electroluxcode]

That's quite a big difference. I'm not sure how Tiptap handles pasting internally, but here's how Slate handles this case: editor.insertTextData splits the text into lines and alternates calling editor.insertText(line) and Transforms.splitNodes(editor, { always: true }).

88% of the total time in insertData is spent normalizing the editor after each split and insertion. It's possible that deferring normalizations until the end of insertData will improve things a little.

Another interesting result is that around 50% of the time spent in `insertData` is spent inside `isEditor`, a utility that's supposed to check if a given object is a Slate editor. Specifically, most of this time is spent inside `isOperationList`, which checks if `editor.operations` is a correctly formed list of operations. Since every operation needs to be checked, and the number of operations increases with each new line of text that has been inserted, this causes the overall time spent in `isOperationList` to have time complexity O(n^2).

I don't see why we should bother validating the exact structure of editor.operations just to determine that an object is a genuine editor. Checking for a property called operations should be more than sufficient.

@electroluxcode Do you want to try experimenting with optimising this?

@12joan
Thank you for the detailed analysis! 🙏 Your approach makes a lot of sense, and simplifying the isEditor check does seem like a smart and efficient improvement

Unfortunately, due to current company business priorities, I won’t be able to dedicate time to this optimization right now. 😔

That said, I’m really looking forward to seeing you tackle this performance issue!