Performance issue with enabled wikEd in preferences but disabled wikEd with the wikEd-enable-button at large pages
Closed, DeclinedPublic
Actions

Assigned To

Authored By

	Boshomi
	Aug 9 2016, 4:21 AM

Description

There is a performace problem with wikEd at large pages.

Steps to reproduce the issue:

disable wikEd in preferences
open a page with a lot of wikitext in editmodus. (>50000Byts) eg. https://de.wikipedia.org/w/index.php?title=Liste_der_Kommunalwappen_mit_der_Jakobsmuschel_in_Frankreich&action=edit
Change some text

→ no issue

enable wikEd in preferences
disable wikied with the wikEd-enable-button (there is no difference if you to this with the button right at the top or with the enable-button in the wikEdButtonBarWrapper
even with disabled wikEd editing slows down. One of the CPU-threads reaches 100% for while typing. The display of the text is far behind typing, while the CPU-thread is still at 100%.
if the change in article is ready, editing the summary is also very slow.

→ performance issue

I think I saw this issue first time some months ago. Chrome is worse then Firefox, but you can see the issue in both browsers, Chrome and Firefox. While editing 50K pages with Chrome, it slows down significant. Firefox slows down significant at 150K, but has a far better performance then Chrome on bigger pages.

(my main use case for using WikEd is the awesome regexp-replace function and wikEd-diff)

What do I expect: no performace lost when editing a page with disabled wikEd

Related Objects

Mentioned In: T142137: While editing textarea gets empty

Event Timeline

Boshomi created this task.Aug 9 2016, 4:21 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2016, 4:21 AM

Boshomi mentioned this in T142137: While editing textarea gets empty.Aug 9 2016, 4:24 AM

Boshomi updated the task description. (Show Details)

Boshomi reassigned this task from • AlexMonk-WMF to Cacycle.Aug 9 2016, 1:36 PM

Boshomi added a subscriber: • AlexMonk-WMF.

I can't reproduce this. I get about the same performance with wikEd (disabled) and without it. (As a side note, the performance is pretty poor, Chrome's debugger tells me it drops to ~15 FPS or so, which is pretty weird for just text editing. I'll file some bugs.)

@Boshomi You might want to record and upload a CPU profile using Chrome's developer tools, so that we can see what code is being slow. Do this twice, once with wikEd and once without it, for comparison.

Open a page for editing (with &debug=1 please, e.g.: click), open the dev tools with Ctrl+Shift+I, go to Profiles → Record JavaScript CPU Profile → Start. Type for a few seconds, then click Stop. You can save it to a file with the Save link on the left sidebar. Note that it may include some private data (depending on what gets recorded, it's possible to figure out what browser extensions you're using, or your on-wiki preferences), but nothing scary like password or cookies. Once you upload the file, anyone can load it with Profiles → Load and analyze it.

(It's also possible to record a "Timeline", which focuses on non-JavaScript things that the browser does, like actually rendering the page. I think a CPU profile is more useful here.)

I cannot reproduce this under Firefox 47.0 20160604131506 and Chrome 52.0.2743.116 m. There is actually a spike in CPU usage, but you see also with wikEd disabled. It seems to be related to the page preview and it might have to do with the large number of SVG images.

There is an evidence of this issue in dewiki village pump:

https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia/Archiv/2016/Woche_30#Wenn_ich

I can reproduce this issue on Linux and Windows.

a good testpage ist this: https://de.wikipedia.org/w/index.php?title=Wikipedia:WikiProjekt_Weblinkwartung/Toter_Link/Liste_dfb_index_2&action=edit

add some chars and watch the display and cpu usage.

There is a big difference if wikEd is switched off in preferences or it is switched off in menue-bar of wikEd

@Boshomi: Can you please provide actual data? See T142461#2536499 for a how-to. Thanks!

@Boshomi: If you can still reproduce this, can you please provide actual data? See T142461#2536499 for a how-to. Thanks!

@Boshomi: Hej hej! Did using the web browser's developer tools help a bit in order to track this issue down?

yes, I think the difference between ff and chrome is small since chrome 53, so I think it was a chrome issue for version 46-51 52?

@Boshomi: Does that imply that you cannot reproduce the problem anymore with 'modern' web browsers?

In T142461#3153632, @Aklapper wrote:

Does that imply that you cannot reproduce the problem anymore with 'modern' web browsers?

Unfortunately closing this report as no further information has been provided.
@Boshomi: Please reopen this report (by changing its status) after you have provided the information asked for and if this still happens. Thanks!

Performance issue with enabled wikEd in preferences but disabled wikEd with the wikEd-enable-button at large pagesClosed, DeclinedPublicActions

Description

Related Objects

Event Timeline

Performance issue with enabled wikEd in preferences but disabled wikEd with the wikEd-enable-button at large pages
Closed, DeclinedPublic
Actions