Pasting text with 10k lines is slow

[bradleyayers]

I'm testing the scalability of Draft.js and one of the scenarios I'm exploring is pasting a large amount of text. A plausible use-case would be if someone's pasting the content of a large source code file.

I was testing with https://facebook.github.io/draft-js/ and generated text content using:

printf '.\n%.0s' {1..10000} | pbcopy

This copies 10,000 lines (each with a single .) to the clipboard. Pasting this into Draft.js (the demo at https://facebook.github.io/draft-js/ will do) demonstrates the performance issue.

It looks like the time is tied up in React. What approach can we take to fix this?

CPU profile: CPU-20160603T133957.cpuprofile.zip

[zpao]

One thing worth nothing is that the Draft home page is using the development version of React. If you're going to analyze performance make sure you use the production minifed version. Not to say there won't be some issues with large amounts of text but that's a first step.

[hellendag]

It would also be useful to see comparisons with other web editors to know whether this is something that is unique to Draft, and to know whether edit operations are sluggish.

[bradleyayers]

At the moment I've shortlisted ProseMirror and Draft.js as candidates to build an editor on, so I only compared performance of those two. Here's the testing environment:

• iOS (iPhone 6S) Safari with profiling enabled (via OSX Safari) — so these times are worse than a user would experience, but are indicative of computational complexity
• Draft.js was the example on https://facebook.github.io/draft-js/ (which is
• ProseMirror was the example on http://prosemirror.net/#demos
• Times are in seconds, the average of a single sample of size two, and measuring script execution only

Scenario	Draft.js	ProseMirror
Pasting 1,000 lines, 100 char per line	8.77s	1.97s
Pasting 1,000 lines, 1 char per line	4.02s	0.15s
Pasting 100 lines, 1000 chars per line	5.32s	2.37s
Pasting 100 lines, 100 char per line	1.10s	0.10s
Pasting 100 lines, 1 char per line	0.68s	0.07s
Press return 5 times after 1,000 lines, 1 char per line	6.94s	0.15s
Press return 5 times in the middle of 1,000 lines, 1 char per line	5.62s	0.27s
Press return 5 times before 1,000 lines, 1 char per line	4.04s	0.45s
Initialise 100 editors, each with 100 char	2.74s	0.31s
Initialise 10 editors, each with 100 char	0.34s	0.08s

You can see ProseMirror is often an order of magnitude faster.

[hellendag]

Thanks for the details!

As @zpao notes, it would be appropriate to test this with the production version of React rather than the development version. (That's not to say PM isn't faster than Draft -- it may well be! But the comparison should be with production React.)

[dmsnell]

Just to chime in I'm also experiencing this issue in automattic/simplenote-electron#501

The editor performance is fine when updating the content once it's already rendered but the load time is slow. Some basic investigation revealed that most of the time when initially rendering the editor was spent in Firefox in the garbage collector.

We're using ContentState.createFromText( someString, '\n' ) but I've timed that and it doesn't appear to take much time. As much as I can figure out tonight, most of the time is spent allocating and freeing objects used in building draft blocks.

@hellendag if there's anything I can do to help out I would be glad to offer my assistance. There are some pictures of dev tools snapshots in the linked issue with Simplenote. Just to repeat as well, this doesn't not appear to be problematic when editing contents already in the editor, just when loading the content into the editor at once.

Even corresponding to the chart above I think this is more proportional to the number of actual lines and not to the number of characters in the editor. For example, and maybe @bradleyayers can help clarify, but I'm guessing that 100/1000 ends up wrapping around to make far more than 100 lines; 100/100 wraps to expand out to a reasonable size, maybe 200 actual lines, and 100/1. Those counts would more closely correlate rendered lines with render time. I did try to test this theory out by timing the render on a wide window and also on a narrow window but did not find a noticeable difference in delay though.

[davidawad]

I've experienced slowness with as few as 3,000+ words even in plaintext mode. (See my application here: https://thoth-reader.herokuapp.com).

Source code is a pretty simple react app that uses the editor for parsing some text. link here.

[tbredin]

We're seeing a sudden and quite severe slowdown in the editor when working with about 1500 lines of text. On a lower end machine we are dealing with a ~6 second delay once typing stops, before visual feedback that typing has occurred.

Will update if I can figure out more info about whats going on here 🤔

[mrkev]

@davidawad, I was curious so I ran a quick profile into your app. I pasted a big chunk of text and pressed enter a few times:

generateTextScores and other functions you run take a long time. Didn't dig much deeper but it seems to be your app's code. I'd suggest looking into debouncing and optimizing it.

@tbredin let us know if draft seems to be the issue.