Page MenuHomePhabricator

[DO NOT USE] VisualEditor: Performance issues (tracker) [superseded by #VisualEditor-Performance]
Closed, InvalidPublic


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



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:57 AM
bzimport set Reference to bz49685.

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

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

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!

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

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.

Stopped script warning


slow2.png (1×1 px, 355 KB)

Firefox chokes

This happens /before/ script-stop warnings.


slow1.png (1×1 px, 398 KB)

another stopped sript warning


Screenshot_from_2013-06-30_21:48:12.png (1×1 px, 482 KB)

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 claimed this task.
Jdforrester-WMF removed subtasks: 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.

Phabricator_maintenance renamed this task from VisualEditor: Performance issues (tracker) to [DO NOT USE] VisualEditor: Performance issues (tracker) [superseded by #VisualEditor-Performance].Aug 5 2016, 2:22 PM
Phabricator_maintenance changed the task status from Resolved to Invalid.
Phabricator_maintenance removed Jdforrester-WMF as the assignee of this task.
Phabricator_maintenance lowered the priority of this task from Medium to Lowest.