Description of problem: For strings of approximately 2 or more paragraphs, the editor becomes less responsive: characters do not appear immediately when typing and selection is unresponsive. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Open any project for which you have edit permission 2.Focus an editor and enter a lot of text Actual results: Editor becomes less responsive. Expected results: Editor remains responsive with the longest strings that are common in translation projects. Additional info: Validators can be disabled to gain some responsiveness, but validators are not the only cause of unresponsiveness.
I am not able to reproduce the bug myself, so assigning it to the QE folks to verify if it's still an issue.
This still appears to be a problem, when entering text at around the 100-150 line mark. Will begin investigating performance profiling after 3.0
It appears that the problem lies in codemirror-compressed.js Firstly, on every keystroke the separatorStart ~ validate chain is executed, which eventually calls codemirror-compressed.js. Secondly, pasting a large amount of text into a target calls codemirror-compressed.js immediately. In both instances, codemirror-compressed is using most of the cpu time. Apparently the newer version of codemirror is faster, but not backwards compatible (I've verified the latter affects the Zanata project). The first scenario could be mitigated somewhat with a delay on validation.
Is any of this reproducible with the CodeMirror v2 demo pages? http://codemirror.net/2/ Perhaps it's time we looked at Ace again, since CodeMirror's updates never seem to be backwards compatible. I wonder if Ace is any better in that respect? http://ace.c9.io/
Created attachment 790764 [details] New codemirror-compressed.js generated at codemirror
Created attachment 790765 [details] Firebug cpu profile (firefox)
I spent a day trying to integrate ACE editor into zanata but can't get it to display. Someone else may want to give it another try :)
Created attachment 790767 [details] Devtool cpu profile (Chrome)
Have the same problem in https://translate.engineering.redhat.com/webtrans/translate?project=pulseaudio&iteration=3.0&localeId=de&locale=en#view:doc;doc:pulseaudio In Element 82, which is quite long, when I change a word, the screen darkens, all other instances of Firefox stop and get dark as well and the screen comes back after more than a minute with: A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: https://translate.engineering.redhat.com/webtrans/8FFF49013CA6B6246B74B521AFC75003.cache.html:4411
There is some improvement to moderately sized text, but large amounts of text that take in excess of one second to validate still encounter significant issues when the one second forced timeout kicks in. Considering that a large block of text is an unusual (though supported) use case for translating documents, validations could be reasonably expected to behave differently, e.g - Longer timeouts on input breaks, - Longer forced timeouts, or - Forced manual validation This would raise a few questions as to what is a "big" block of text.
Let's just remove the forced timeouts. We don't need them. We can just wait until the user stops typing, then do the validation. We should probably look at optimising the slowest validations too, but that should be separate. Also, when the validation takes more than a second, we should display something to let the user know what's happening. And perhaps we can break the work into multiple pieces to avoid hurting interactivity: http://stackoverflow.com/a/15284868/14379
On the subject of slow validations, if the validation takes longer than, say, 200 ms, we should just abort the client-side validation with a warning, and let the server check upon save. (For bonus points, we could ask the server to perform the validation for us on the fly, but it's probably not worth the bother.)
https://bugzilla.redhat.com/show_bug.cgi?id=906172#c12: https://github.com/zanata/zanata-server/pull/332
Waiting for https://github.com/zanata/zanata-server/pull/358 merge before retest.
https://github.com/zanata/zanata-server/pull/358 has been merged.
There still appears to be a crippling performance issue (45s to handle 4 entered characters) when in plain text editing mode.
I will close this bug. Looks like it will only slow on relatively "large" trunk of text.