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

Attached:

Firefox chokes

This happens /before/ script-stop warnings.

Attached:

another stopped sript warning

Attached:

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.