๐ Bug report
Classic editor : ckeditor5/10.0.1 (from the demo page through CDN)
Obtained from : https://docs.ckeditor.com/ckeditor5/latest/builds/guides/quick-start.html
@Mgsy Could you check if there's some breaking point at which this fails? Or is it happening gradually?
Also, does it happen if there are no <div>s inside the content? The thing is that <div>s are not supported by any of the features so they get rejected. There's a chance that the algorithm handling unhandled nodes has some issues.
I've checked this case and here are my observations:
<div> elements inside the content.Some stats:
With <div> in the content:
Fast machine - loading time: 29s
Slow machine - loading time 1m08s
Without <div> in the content:
Fast machine - loading time: 9s
Slow machine - loading time: 28s
Generally, the loading time increases with raising amount of elements.
Thanks!
9s is still not a great time, but 3500 paragraphs is a lot of content. Actually, I'm curious when in real life people are editing such a long text. @bagelparser, did you encounter this when testing performance on purpose or do you really work with such a long text? Did you consider splitting this into multiple editors (e.g. so you edit one chapter of a book at once)?
As for what to do next โ this issue requires profiling. But I don't think that exceeding 300 paragraphs happens often so optimising editor performance for 3500 nodes is not going to be high on our priority list (at least at this stage).
Note to myself โ I just checked that my longest article ever (or rather โ "so far") exceeded 100 paragraphs and it was 14 pages long. Google Docs start to lag at around 90+ pages so that would be theoretically 900 paragraphs . Just to put that 3500 nodes into a perspective :)
We routinely have documents that have more than 3500 elements in them. Real-life examples that came up in our testing (for CK4 mind you) can be comparable to War and Peace by Leo Tolstoi, which stands at around 16000 HTML elements on Gutenberg. Another one : "Great Expectations", Charles Dickens on Gutenberg (~4800 elements).
We have some more complicated examples with tables, figures, etc... These can sometimes be up to 500 pages long (in PDF preview).
We have considered per-chapter editting, but this greatly removes from the user experience (no global search, find & replace, multiple tabs, etc...).
Currently, these performance issues are preventing us from porting over to CKEditor 5 from CKEditor 4.
I'm sure we could find even longer novels. That wasn't my point that I wrote the longest article ever :D The point was โ such a long content doesn't have to necessarily be edited at once. Also, if we'd ever make the editor able to handle such a long content, you can always find N times longer things (e.g. HTML5 living spec which soon will be the longest text ever created by men).
CKEditor 5 has a much richer data model and much more logic that controls and renders it than CKEditor 4 (which did everything in-place, in the DOM, so only the browser was a real limitation). This approach must, by definition, be slower than what CKEditor 4 offers. We can spend time optimizing it, but we'll never reach the same level of performance. Nor will any other application which wasn't designed with this requirement in mind. It's a tradeoff one needs to make.
Anyway, I'm quite sure there's a lot that we could optimise in the current implementation. Performance, simply, wasn't our goal yet. If you'd like to discuss this option, please contact us at https://ckeditor.com/contact/.
But at the same time, I recommend considering a bit different approach to handling such a long content.
We have considered per-chapter editing, but this greatly removes from the user experience (no global search, find & replace, multiple tabs, etc...)
This problem has been already solved by many IDEs (features such as "Find in files", "Replace in files" etc.) - it is possible to guarantee proper UX allowing people to split content into smaller chunks (files in this example).
When someone works on a specific chapter and make use of "replace" he may be presented just an additional option "Replace in all chapters" etc.
Most helpful comment
This problem has been already solved by many IDEs (features such as "Find in files", "Replace in files" etc.) - it is possible to guarantee proper UX allowing people to split content into smaller chunks (files in this example).
When someone works on a specific chapter and make use of "replace" he may be presented just an additional option "Replace in all chapters" etc.