VisualEditor: Performance issues (tracker)
Closed, ResolvedPublic

Description

This is more of a tracking bug than anything else, but it should be something people are aware of and something that's formally logged; the VisualEditor is very slow on large articles, to the point where it causes confusing output.

Using the example of https://en.wikipedia.org/wiki/OpenOffice - I edited this and it took a good 20 seconds just to render 'review changes', and another 20 to save. David Gerard did the same and the server popped up "Error saving data to server: timeout." with both 'review' and 'save'. Despite this, it saved anyway.

Obviously as a long-term thing: we shouldn't have an editor so slow that someone in an industrialised, Western nation (i.e. the UK) can't make things work.[1] As a short-term thing, we shouldn't be informing users "something has gone terribly, terribly wrong, abort!" when it has actually saved.

[1] It's David Gerard, he's not going to be using dial-up.


Version: unspecified
Severity: normal

bzimport set Reference to bz49685.
Ironholds created this task.Via LegacyJun 17 2013, 11:18 AM
bzimport added a comment.Via ConduitJun 17 2013, 12:09 PM

dgerard wrote:

Specifically, 8Mbit ADSL through Zen. Most of the slowness appears to be thinking - I could hear my laptop's CPU fan speed up.

Jdforrester-WMF added a comment.Via ConduitJun 17 2013, 6:57 PM

Listing the issues so it's clear what we mean by "performance issues" and their different causes and artefacts:

  • [network] VE slow to load own JS - mostly provided by ResourceLoader and local cacheing so this would only be a slowness once per user's browser (assuming they don't clear their local cache); we could pre-load VE JS for all users on read, which would reduce load times when people press edit slightly, but that is evil
  • [network] VE slow to fetch HTML from Parsoid - mostly fixed due to highly-aggressive caching at our cluster (the payload is slightly smaller in byte size than the read page fetch, i.e. not significant)
  • [client] VE slow to render Parsoid HTML into an editable document - we're working on this (profiling etc.), but there's a tension between editability and simplicity of data structure. :-)
  • [client] VE slow to respond to user action - same as above; this is the core "performance" area for VE itself, of course
  • [server] VE slow to get a wikitext diff - this relies on two operations; a Parsoid serialise and an MW wikitext diff: we can work with Parsoid on that being faster, but there's a limit; theoretically we could pre-serialise as we go (but eww network traffic and load on the servers)
  • [server] VE slow to save edit - this is essentially the same performance issue as getting the wikitext diff, above; theoretically we could optimise by saving the output of the serialise from a wikitext diff, but this won't be triggered for most users, so it's of marginal utility
bzimport added a comment.Via ConduitJun 17 2013, 7:04 PM

dgerard wrote:

It may also be worth noting that this page takes ~30 seconds in my use to save when using the ordinary source wikitext editor - it's a complex page!

Jdforrester-WMF added a comment.Via ConduitJun 17 2013, 7:21 PM

(In reply to comment #3)

It may also be worth noting that this page takes ~30 seconds in my use to
save when using the ordinary source wikitext editor - it's a complex page!

Yes, one of the problems is that VE being slow is rather more noticeable than MW being slow (because "it's a website" and so triggers different time response expectations in users). :-(

bzimport added a comment.Via ConduitJun 18 2013, 1:00 PM

dgerard wrote:

It was previously doing a very dirty diff; I just tried again on this article and it did a clean diff, but timed out when I hit "save", three times in a row, and didn't actually save any of them.

Ironholds added a comment.Via ConduitJun 30 2013, 7:41 PM

Stopped script warning

Attached:

Ironholds added a comment.Via ConduitJun 30 2013, 7:41 PM

Firefox chokes

This happens /before/ script-stop warnings.

Attached:

AzaToth added a comment.Via ConduitJun 30 2013, 7:51 PM

another stopped sript warning

Attached:

bzimport added a comment.Via ConduitMar 1 2014, 8:57 AM

dgerard wrote:

Update on the test Oliver mentions at the top: on the same PC and the same Internet connection (though a current version of Firefox), it just now took:

It's a ... test subject ... of a page.

Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 1:29 AM
Jdforrester-WMF closed this task as "Resolved".Via WebDec 2 2014, 9:38 PM
Jdforrester-WMF claimed this task.
Jdforrester-WMF removed blocking tasks: T70042: When saving a page, only send back to Parsoid the parts of the page that have been changed, T66171: Log Parsoid server-side save performance, T67512: VisualEditor: Language selector from Language inspector takes long time (~15 secs) to load, T67453: VisualEditor: From a cold start using debug=true, there's no indication VE is loading for a few seconds; move some init stuff further up?, T68914: VisualEditor: Compress POST data in the client, T53569: Reduce number of load.php calls on VisualEditor open (down from 3), T59952: Pre-fetch VisualEditor modules to improve load speed, T66772: On VisualEditor load, async pre-load all the TemplateData for the page to make editing templates speedier, T55093: For very large pages on slow connections (when a timeout happens?), users get an "Error: Unknown error" on saving changes in VisualEditor (but change is indeed saved), T66709: VisualEditor: ve.ce.ProtectedNode.prototype.onProtectedSetup is a performance hog, T53202: Draw VisualEditor's non-CE block highlights using SVG polygons, T64812: VisualEditor: setResizableHandlesSizeAndPosition() shouldn't measure things on every keypress, T64755: Improve VisualEditor's performance on tablet devices, T52616: Improve VisualEditor's loading performance in Firefox, T54365: Explore performance gains from progressive (JIT?) de-alienation in VisualEditor, T55826: Lazy load extensions' large resources in VisualEditor, rather than blocking load, T55825: Reduce VisualEditor's memory usage, T54012: Typing plain text into a large page is very slow, T52084: VisualEditor: Lag when selecting complex templates (especially in big pages).

Let's use VisualEditor-Performance instead.

Krinkle moved this task to Done on the VisualEditor-Performance workboard.Via WebMar 19 2015, 10:35 PM

Add Comment