Last modified: 2014-11-18 20:51:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51685, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49685 - (ve-performance) VisualEditor: Performance issues (tracker)
VisualEditor: Performance issues (tracker)
Product: VisualEditor
Classification: Unclassified
General (Other open bugs)
All All
: Normal normal
: ---
Assigned To: Editing team bugs – take if you're interested!
: performance, tracking
Depends on: 50616 51202 51569 52365 53093 53825 53826 57952 62755 64171 64772 68042 50084 52012 62812 64709 65453 65512 66914
Blocks: tracking ve-tracking
  Show dependency treegraph
Reported: 2013-06-17 11:18 UTC by Oliver Keyes
Modified: 2014-11-18 20:51 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Stopped script warning (355.50 KB, image/png)
2013-06-30 19:41 UTC, Oliver Keyes
Firefox chokes (398.36 KB, image/png)
2013-06-30 19:41 UTC, Oliver Keyes
another stopped sript warning (482.28 KB, image/png)
2013-06-30 19:51 UTC, Carl Fürstenberg

Description Oliver Keyes 2013-06-17 11:18:16 UTC
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.
Comment 1 David Gerard 2013-06-17 12:09:49 UTC
Specifically, 8Mbit ADSL through Zen. Most of the slowness appears to be thinking - I could hear my laptop's CPU fan speed up.
Comment 2 James Forrester 2013-06-17 18:57:31 UTC
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
Comment 3 David Gerard 2013-06-17 19:04:38 UTC
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!
Comment 4 James Forrester 2013-06-17 19:21:06 UTC
(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). :-(
Comment 5 David Gerard 2013-06-18 13:00:22 UTC
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.
Comment 6 Oliver Keyes 2013-06-30 19:41:24 UTC
Created attachment 12702 [details]
Stopped script warning
Comment 7 Oliver Keyes 2013-06-30 19:41:48 UTC
Created attachment 12703 [details]
Firefox chokes

This happens /before/ script-stop warnings.
Comment 8 Carl Fürstenberg 2013-06-30 19:51:20 UTC
Created attachment 12704 [details]
another stopped sript warning
Comment 9 David Gerard 2014-03-01 08:57:51 UTC
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:

* 10 seconds to open [[]]
* 176 seconds (nearly three minutes!) to render the "Review your changes" diff
* two minutes attempting to save, then "Error: Unknown error". The edit did, however, save:

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

Note You need to log in before you can comment on or make changes to this bug.