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

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.