Last modified: 2014-11-18 20:51:11 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 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.
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.
Created attachment 12702 [details] Stopped script warning
Created attachment 12703 [details] Firefox chokes This happens /before/ script-stop warnings.
Created attachment 12704 [details] another stopped sript warning
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 [[OpenOffice.org]] * 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: https://en.wikipedia.org/w/index.php?title=OpenOffice.org&diff=597641893&oldid=593809275 It's a ... test subject ... of a page.
