Quill: Document Length Affects Typing Performance -- 1.0.0-beta.5

[danielschwartz]

Hi,

I've been playing around with the new version of Quill -- and it's awesome. I was about to sign off and start trying to integrate it into my application when I noticed that as the document grows in length typing begin to slow down to the point where there is a very noticeable lag. Format changes seem to happen just as quickly so it seems it's the addition (or removal) of text that is slow.

Is this expected behavior right now? If it is, is there a timeline to getting performance tuned? Should I not be asking these questions while this is in beta?

Steps for Reproduction

1. Visit http://beta.quilljs.com/standalone/snow/
2. Insert large document (~500 lines)
3. Try typing anywhere in the document, notice the lag

Expected behavior: A performance slow down is obviously expected as the document grows extremely large, however I would expect the slowdown to only become noticeable well beyond 500 lines
Actual behavior: Laggy typing

Platforms: Chrome 51 on OSX 10.11.3

Version: 1.0.0-beta.5

[jhchen]

Performance is important though correct functionality is more of a focus right now, barring unusable performance. Right now changes from typing or formatting scales with the number of rich-text operations, not necessarily lines, so 10000 plaintext lines would perform faster than 1000 bulleted lines. There are a number of places where memoization would help a lot but then invalidation needs to be managed, which would be much easier to deal with once functionality is solid with a strong test suite.

In any case I did find some low hanging fruit in the rich-text library that did dramatically reduce typing lag. On 1000 bulleted lines there was 200-300ms lag whereas after the change its in the low 30s. You can decide in the next beta release if this is sufficient.

[danielschwartz]

@jhchen thanks for the super quick reply on this! Appreciate the clarification on getting the underlying APIs/functionality right and then moving onto performance -- makes complete sense to me (and feels like the correct move).

Excited to see the performance gains from the changes you mentioned coming in the next beta. Thanks again for the quick response and detailing your thought process on the betas!

[jhchen]

@danielschwartz Can you check the most recent beta version on http://beta.quilljs.com and see how that feels?

[danielschwartz]

@jhchen sorry about the delay. Ill likely get a chance to test this sometime this week. Our users have some fantastically long docs so those will provide a great pool of documents to test with

[danielschwartz]

@jhchen so I gave this a whirl in my local development copy on the v1.0.0-beta.11 tag:

I took a document of medium length that we have. In quill it has 667 child nodes (accomplished by calling $('.ql-editor').children.length) and had a very slight slow down, but was definitely still useable.

I also took the longest document we have. In quill it has 7538 child nodes and is completely unusable (the lag on keypresses can approach 5-7 seconds per keypress). While this document is definitely an outlier, I never want document length to be the thing that affects performance (because saying "well your document is too long, make a new one" isn't really an acceptable answer to our customers 😄)

Everything else about the 1.0 version of Quill is incredibly intriguing, so if you think that performance gap can be made up, we would absolutely look at adopting Quill as our editor (and obviously contribute bug fixes/changes upstream).

[jhchen]

Can you post or email me an example non-sensitive worst case document? I can try out a 7k line doc myself but I might miss some important characteristics. I actually did test out a 10k line doc, but mostly plaintext, and lag was noticeable but usable.

[danielschwartz]

@jhchen yup, ill send you an email with a text file containing the HTML that is copied to the clipboard from our editor (which i'm then pasting into Quill). It might take me a couple days as the document i'm using has sensitive material, so ill have to construct a similar but new document that doesn't include anything sensitive.

Look out for an email from me in the next couple days or so!

[jhchen]

Number of operations no longer linearly affects typing as the memoization strategy discussed above has been employed many releases ago.