Last modified: 2014-08-26 06:16:32 UTC
Typing on a pad with about 700 lines is practically impossible due to excessive lag, caused by CPU load. Chrome on fedora 18, Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz: 140 % CPU Chromium on fedora 18, AMD E-350: all CPU available (100 %) Chrome or Firefox on OS X, unknown CPU (by etherpad dev): 10 % CPU? This is a blocker for bug 45312 because etherpad.wmflabs.org can't cover basic needs for our use cases. Bug upstream still to be filed: «profile it using the chrome-dev-tools, "Collect javascript CPU profile"». (Apparently they consider 700 lines to be a lot and our CPUs to be too slow, we'll see how hard it is.)
(In reply to comment #0) > Typing on a pad with about 700 lines is practically impossible due to > excessive lag, caused by CPU load. > Chrome on fedora 18, Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz: 140 % CPU > Chromium on fedora 18, AMD E-350: all CPU available (100 %) > Chrome or Firefox on OS X, unknown CPU (by etherpad dev): 10 % CPU? From what you list there only seems to be an issue in Chrome. Using Firefox 18.0.2 on Fedora and http://etherpad.wmflabs.org/pad/p/test , I can write totally fine in line 1100. I can confirm that Google Chrome 24.0.1312.69 feels sluggish. > This is a blocker for bug 45312 because etherpad.wmflabs.org can't cover > basic needs for our use cases. It's not if so far only one person is affected, in one specific configuration (workaround: Use a different browser), and not sure how often we have such large Etherpad files either (though I can imagine for buglists on bugdays).
By the way, this component does not appear to have any default CCs. Andre, could you try to track down a maintainer and add them?
(In reply to comment #1) > It's not if so far only one person is affected, in one specific configuration > (workaround: Use a different browser), and not sure how often we have such > large Etherpad files either (though I can imagine for buglists on bugdays). The Language Engineering team has this all the time, as all of out meeting notes are on etherpad. See for example http://etherpad.wmflabs.org/pad/p/l10n-team. Two days into the test of Etherpad Lite, we seem to have to go back to regular Etherpad.
(In reply to comment #1) > From what you list there only seems to be an issue in Chrome. No, there's no reported difference between Chrome/Chromium and other browsers.
Errm, in comment 0 you wrote that Firefox maybe takes 10% but Chrome takes 140% CPU. Plus I don't have problems in Firefox. How does that go together?
(I didn't receive bugmail for half of the comments above, unsure why.) (In reply to comment #5) > Errm, in comment 0 you wrote that Firefox maybe takes 10% but Chrome takes > 140% > CPU. Plus I don't have problems in Firefox. How does that go together? No, I said that both Firefox and Chrome have 10 % CPU usage for that dev who tested. Do you experience a difference between the two browsers?
As Andre said in comment 1: "I can confirm that Google Chrome 24.0.1312.69 feels sluggish." I also, can confirm that Fx 22.0a2 is NOT sluggish, while Chromium 26.0.1410.43 IS sluggish (both on Debian). So, again, a reasonable workaround for now is to use Firefox for etherpad lite, but tracking down the real culprit (Chromium? Etherpad life?) should happen. Does someone want to determine where the issue lies and report that problem to the relevant upstream?
(In reply to comment #7) > Does someone want to determine where the issue lies and report that problem > to > the relevant upstream? Greg, the upstream report was already linked: https://github.com/ether/etherpad-lite/issues/1763 There was a rush before last release and devs debugged it a lot, but didn't find a real solution yet.
Upstream comment implies that reason might be https://bugs.webkit.org/show_bug.cgi?id=92594 for WebKit browsers.
A recently (14 July) merged patch allegedly makes the most common case one order of magnitude faster, worth testing. https://github.com/ether/etherpad-lite/issues/1763#issuecomment-21423689 https://github.com/ether/etherpad-lite/pull/1833#issuecomment-20943600
(In reply to comment #10) > A recently (14 July) merged patch allegedly makes the most common case one > order of magnitude faster, worth testing. > https://github.com/ether/etherpad-lite/issues/1763#issuecomment-21423689 > https://github.com/ether/etherpad-lite/pull/1833#issuecomment-20943600 Did it? Are we using that code or not? We no longer have the old etherpad as workaround, how are people managing?
(In reply to comment #11) > (In reply to comment #10) > > A recently (14 July) merged patch allegedly makes the most common case one > > order of magnitude faster, worth testing. > > https://github.com/ether/etherpad-lite/issues/1763#issuecomment-21423689 > > https://github.com/ether/etherpad-lite/pull/1833#issuecomment-20943600 > > Did it? Are we using that code or not? We no longer have the old etherpad as > workaround, how are people managing? I hear that some are still using Chrome to edit the etherpads in question; it gets very slot to use about now, so around 1700 lines it would seem? For reference, https://etherpad.wikimedia.org/p/i18n-team-04/timeslider#10309
I'm bumping this down to major as there is a simple workaround (use a different browser) and as it's not critical by definition of https://www.mediawiki.org/wiki/Bugzilla/Fields#Severity
Just in case someone wonders, this is still relevant and LangEng is still using Google Docs because of this bug.
