https://bugzilla.wikimedia.org/show_bug.cgi?id=49685

James Forrester <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Unprioritized               |Normal
             Status|NEW                         |ASSIGNED
                 CC|                            |[email protected]
             Blocks|                            |2007
            Summary|VisualEditor: slow to       |VisualEditor: Performance
                   |handle large articles       |issues (tracker)

--- Comment #2 from James Forrester <[email protected]> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to