Bug 906172 - Editor becomes slow when working with a long string
Editor becomes slow when working with a long string
Product: Zanata
Classification: Community
Component: Component-UI (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Alex Eng
Damian Jansen
Depends On:
  Show dependency treegraph
Reported: 2013-01-30 23:33 EST by David Mason
Modified: 2015-03-10 20:42 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-03-10 20:42:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
New codemirror-compressed.js generated at codemirror (143.26 KB, text/javascript)
2013-08-27 01:21 EDT, Damian Jansen
no flags Details
Firebug cpu profile (firefox) (868.32 KB, text/html)
2013-08-27 01:22 EDT, Damian Jansen
no flags Details
Devtool cpu profile (Chrome) (87.99 KB, text/html)
2013-08-27 01:26 EDT, Damian Jansen
no flags Details

  None (edit)
Description David Mason 2013-01-30 23:33:03 EST
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:

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.
Comment 1 Michelle Kim 2013-07-10 02:11:17 EDT
I am not able to reproduce the bug myself, so assigning it to the QE folks to verify if it's still an issue.
Comment 2 Damian Jansen 2013-08-08 23:49:16 EDT
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
Comment 3 Damian Jansen 2013-08-26 19:33:34 EDT
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.
Comment 4 Sean Flanigan 2013-08-26 21:00:29 EDT
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/
Comment 5 Damian Jansen 2013-08-27 01:21:14 EDT
Created attachment 790764 [details]
New codemirror-compressed.js generated at codemirror
Comment 6 Damian Jansen 2013-08-27 01:22:46 EDT
Created attachment 790765 [details]
Firebug cpu profile (firefox)
Comment 7 Patrick Huang 2013-08-27 01:26:39 EDT
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 :)
Comment 8 Damian Jansen 2013-08-27 01:26:50 EDT
Created attachment 790767 [details]
Devtool cpu profile (Chrome)
Comment 9 Rainer Gromansperg 2013-10-18 01:00:40 EDT
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
Comment 11 Damian Jansen 2013-10-27 21:59:43 EDT
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.
Comment 12 Sean Flanigan 2013-10-27 23:25:36 EDT
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
Comment 13 Sean Flanigan 2013-11-26 23:37:30 EST
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.)
Comment 15 Damian Jansen 2014-02-09 20:46:07 EST
Waiting for https://github.com/zanata/zanata-server/pull/358 merge before retest.
Comment 16 Sean Flanigan 2014-02-14 02:52:04 EST
https://github.com/zanata/zanata-server/pull/358 has been merged.
Comment 17 Damian Jansen 2014-02-16 23:04:44 EST
There still appears to be a crippling performance issue (45s to handle 4 entered characters) when in plain text editing mode.
Comment 21 Patrick Huang 2015-03-10 20:42:36 EDT
I will close this bug. Looks like it will only slow on relatively "large" trunk of text.

Note You need to log in before you can comment on or make changes to this bug.