Page MenuHomePhabricator

Performance issues on very long pages
Open, HighPublic8 Estimated Story Points

Description

URL: https://en.wikipedia.org/wiki/Endorsements_for_the_Republican_Party_presidential_primaries,_2016?veaction=edit

OS X, Chrome. Fast connection but w/ 100ms latency.

Initial load to edit takes ~10s (reproducible)
Delay between keystrokes is very, very long: 15s to finish typing a 10-word sentence. Unusable even for typo correction. (reproducible)

The page is not terribly long, but has almost 1000 cites.

This task generated from feedback left here: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Editing_unusably_slow_on_long_page

Event Timeline

Sj raised the priority of this task from to Needs Triage.
Sj updated the task description. (Show Details)
Sj added a project: VisualEditor.
Sj subscribed.
Sj set Security to None.

Change 269546 had a related patch set uploaded (by Esanders):
Use plain DOM in ve.ce.LinkAnnotation

https://gerrit.wikimedia.org/r/269546

Update from further testing (on a faster cnxn w/ 2ms latency):

  • Not noticeable on Safari. Noticeable on Chrome and (less so) on Firefox.
  • Per-character lag depends on how far down the page the cursor is. Chrome: Fast at the top, slow at the bottom. Firefox: on one page, fast at the bottom, slow at the top...
  • This happens on long pages w/ less interesting markup, but much less noticeable. Test page:

https://en.wikipedia.org/wiki/1918_Birthday_Honours?veaction=edit
At the start of this page, in Chrome, lag is ~1s for a full sentence (waiting for the final letter to be typed after hands up). At the end of the page, lag is ~4s for the same sentence. (In FF, 5s at the start, 0s at the end.)

  • Lag is cumulative, adds up with every keystroke. Not with every character entered — Ctrl-V counts as a single keystroke for arbitrary blocks of text. Despite the growing lag, characters appear on the screen in bunches, not one at a time.

I haven't tested w/ long pages with zero citations; still possible there's a combination of length and {{reflist}}.

Finally, lag varies significantly w/ the same computer setup (mem free, no complex processes running): the initial page reported now has only a 5s delay at the bottom, not a 15s one.

Change 270750 had a related patch set uploaded (by Esanders):
FocusableNode: Bind position events later

https://gerrit.wikimedia.org/r/270750

Esanders renamed this task from Extremely slow & laggy editing for long page w/many citations to Performance issues on very long pages.Feb 15 2016, 3:31 PM

Change 270760 had a related patch set uploaded (by Esanders):
Fix cache invalidation of SurfaceFragment.leafNodes

https://gerrit.wikimedia.org/r/270760

Change 270762 had a related patch set uploaded (by Esanders):
Share getSelectedNode logic between Surface and SurfaceFragment

https://gerrit.wikimedia.org/r/270762

Change 270776 had a related patch set uploaded (by Esanders):
Move selection directionality to ve.ce.Selection

https://gerrit.wikimedia.org/r/270776

Change 270760 merged by jenkins-bot:
Fix cache invalidation of SurfaceFragment.leafNodes

https://gerrit.wikimedia.org/r/270760

Change 270762 merged by jenkins-bot:
Share getSelectedNode logic between Surface and SurfaceFragment

https://gerrit.wikimedia.org/r/270762

Change 270776 merged by jenkins-bot:
Move selection directionality to ve.ce.Selection

https://gerrit.wikimedia.org/r/270776

Change 270750 merged by jenkins-bot:
FocusableNode: Bind position events later

https://gerrit.wikimedia.org/r/270750