-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance research #5880
Comments
It's great to see effort on this topic. As an example I'm attaching a HTML file which takes couple of seconds (5-10 on my machine) to load into CKEditor. The file is big-ish, but still something you might expect to work with in the CKEditor. |
Added subtasks list for better tracking. |
Internal: Added editor setData manual performance test. Part of #5880.
Tests: Added editor setData manual performance test. Part of #5880.
Tests: Added a test with an editor with lots of plugins to make testing interaction between plugins easier for the team (see #5880).
One note – I saw the newly added tests. They use |
tl;dr; for small editors most of the time goes to editor UI rendering (e.g. color dropdowns, table dropdown). In case of editors with a longer content we'd need to optimize data processing. You can load profiles in your inspector from this archive: editor-init-profiles.zip. editorinit - short, semantic contentTotal click handler time 1.14s. Most of the time is consumed by initializing the toolbar (582ms), with font bg/color dropdown taking the longest time to render: Which is similar to #6161. editorinit - medium, semantic contentClick handler execution time 5.94s As editor contains more content, it's no longer the UI - instead lodash's The first issue comes from our Taking a step back and looking at the bigger picture, it's editorinit - long, semantic contentContent stats: 6174 elements, 9.228 text nodes. tl;dr; Click handling took 19.4 s. As the content gets larger you can see that, intuitively, model and editable output takes more time. One thing to note is that edit: added bottom-up list (note, the bottom-up is taken from a different run, where the timing turned out a bit different then above 24.7s in click handler) editorinit - short, styled contentClick handling took 1.48s. In this case time distribution is almost 50%/50% - half going for editor UI view initialization and another half on editable handling (toView, toModel, etc.). editorinit - full website styled contentClick handling took 6.28s. Call graph goes much deeper than previous ones, probably because there's more nested content. Again, lodash's View/model generation takes the most of the time. ConditionsTests were performed on latest |
There are some quick wins possible. I recall seeing Time given in seconds.
Pushed the changes to https://github.com/ckeditor/ckeditor5-utils/tree/i/4504-rebased |
Related ckeditor/ckeditor5-utils#322. |
There are couple of issues created from this one:
Also couple other things could be noted based on research but these probably couldn't be fixed with reasonable effort:
|
It saved ~10ms startup time when switched to ~29ms gain in http://localhost:8125/ckeditor5/tests/manual/performance/richeditor.html. Diff for future reference diff --git a/src/icon/iconview.js b/src/icon/iconview.js
index c33f95a..43dd9cb 100644
--- a/src/icon/iconview.js
+++ b/src/icon/iconview.js
@@ -95,19 +95,13 @@ export default class IconView extends View {
*/
_updateXMLContent() {
if ( this.content ) {
- const parsed = new DOMParser().parseFromString( this.content.trim(), 'image/svg+xml' );
- const svg = parsed.querySelector( 'svg' );
- const viewBox = svg.getAttribute( 'viewBox' );
+ this.element.innerHTML = this.content.trim();
+
+ const viewBox = this.element.firstChild.getAttribute( 'viewBox' );
if ( viewBox ) {
this.viewBox = viewBox;
}
-
- this.element.innerHTML = '';
-
- while ( svg.childNodes.length > 0 ) {
- this.element.appendChild( svg.childNodes[ 0 ] );
- }
}
} |
Tests: Added performance manual tests. Closes #5880.
Let's start from creating a set of manual tests on which we'll be able to reliably and quickly test typical performance-oriented scenarios.
Some ideas for those scenarios:
Other considerations:
Subtasks:
setData
button (Added editor setData manual performance test #6103)The text was updated successfully, but these errors were encountered: