Bug 906172
Summary: | Editor becomes slow when working with a long string | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Zanata | Reporter: | David Mason <damason> | ||||||||
Component: | Component-UI | Assignee: | Alex Eng <aeng> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Damian Jansen <djansen> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 2.1 | CC: | aeng, djansen, mkim, mospina, pahuang, sflaniga, zanata-bugs | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2015-03-11 00:42:36 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
David Mason
2013-01-31 04:33:03 UTC
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. |