(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.

is this still a problem ? We 've bumped many versions of etherpad since then and while the first issue referenced is still open, the PR has been merged. Perhaps we can resolve this these days ?

Do we have a test case? I can't find an easy one...

It seems all test cases were destroyed by etherpad cataclysms, but it's not too hard to create one simply by pasting a long text: https://etherpad.wikimedia.org/p/T48637 consumes 100 % CPU for me with Chromium 43 while I type.

A more realistic test case needs to be created by many users and be very colourful. There were some such pads listed on https://etherpad.wikimedia.org/p/l10n-etherpads but it seems most were destroyed.

Chrome 44 on Debian Linux 8.1 does not exhibit that behavior for me. All I did was click the link https://etherpad.wikimedia.org/p/T48637 and start typing in that pad. CPU usage never went above 40%.

I can not reproduce it and it is already tracked in upstream's issue tracker as https://github.com/ether/etherpad-lite/issues/1763

Closed yesterday.