Page MenuHomePhabricator

Reduce the frequency of DOM scans to rebuild inlines when scrolling revisions

Authored by epriestley on May 15 2020, 4:35 PM.
Referenced Files
F12521264: D21261.diff
Fri, Feb 23, 9:50 AM
Unknown Object (File)
Wed, Jan 24, 2:46 PM
Unknown Object (File)
Jan 17 2024, 4:35 PM
Unknown Object (File)
Jan 12 2024, 1:36 PM
Unknown Object (File)
Jan 8 2024, 10:35 AM
Unknown Object (File)
Dec 26 2023, 12:32 PM
Unknown Object (File)
Dec 24 2023, 5:55 PM
Unknown Object (File)
Nov 30 2023, 12:58 AM



Ref T13513. See PHI1734, which raises a concern about the performance of large revisions near the 100-change threshold.

Currently, getInlines() is called whenever the scroll position transitions between two changesets, and it performs a relatively complicated DOM scan to lift inlines out of the document.

This shows up as taking a small but nontrivial amount of time in Firefox profiles and should be safely memoizable.

Test Plan
  • Under Firefox profiling, scrolled through a large revision.
  • Before change: getInlines() appeared as the highest-cost thing we're explicitly doing on profiles.
  • After change: getInlines() was no longer meaningfully represented on profiles.
  • Created inlines, edited inlines, etc. Didn't identify any broken behavior.

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable