Skip to content

GITHUB 2026-04-03

Read original ↗

The uphill climb of making diff lines performant

Summary

GitHub Engineering describes the year+ rewrite of the Files changed tab in the React-based pull-request review UI (now the default for all users). The forcing function was the extreme-tail shape of GitHub's PR corpus — medium and large PRs were fine, but giant PRs (thousands of files, 10,000+ diff lines) could drive the JavaScript heap over 1 GB, DOM node count past 400,000, and p95+ Interaction-to-Next-Paint (INP) into the 275–700+ ms range — quantifiably sluggish input lag. There was no single silver bullet. The team shipped a PR-size-tiered strategy: per-diff-line component simplification for the median review (v1 → v2), window virtualization via TanStack Virtual for p95+ giant-PR reviews, and compounding foundational improvements (server-side hydrate-visible-only, progressive diff loading, Datadog INP tracking, GPU-transform drag/resize). v1 → v2 alone cut memory ~50 %, component render count ~74 %, and INP on a 10,000-line split diff from ~450 ms to ~100 ms (~78 % faster); TanStack Virtual delivered a 10× reduction in JS heap + DOM nodes on p95+ PRs with INP of 40–80 ms.

Key takeaways

  • Extreme-tail PR sizes are the forcing function, not the median. "For most users before optimization, the experience was fast and responsive" — the problem was that "when viewing large pull requests, performance would noticeably decline", and at PR scale the extreme tail is load-bearing: a single 10,000-line PR breaks a developer's review flow for an entire day. "JavaScript heap could exceed 1 GB, DOM node counts surpassed 400,000, and page interactions became extremely sluggish or even unusable." (Source: article § intro)

  • No silver bullet — PR-size-tiered strategy. The team explicitly rejected the one-solution framing: "Techniques that preserve every feature and browser-native behavior can still hit a ceiling at the extreme end. Meanwhile, mitigations designed to keep the worst-case from tipping over can be the wrong tradeoff for everyday reviews." The three-track strategy: focused diff-line-component optimizations for most PRs (preserves native find-in-page), graceful virtualization for p95+ PRs (trades find-in-page for survivability), foundational component + rendering improvements that compound across every PR size regardless of mode. (Source: article § Performance improvements)

  • v1's small-reusable-component strategy became pathological at scale. Each v1 diff line rendered ≥10 DOM elements in unified view / ≥15 in split view (before syntax-highlighting <span>s), backed by ≥8 / ≥13 React components, with 5-6 React event handlers per component = 20+ event handlers per diff line. At 10,000 lines: 100,000–150,000 DOM elements, 80,000–130,000 React components, 200,000+ event handlers. "This is a familiar scenario where you implement an initial design, only to discover later its limitations when faced with the demands of unbounded data." (Source: article § v1)

  • v2 = component-tree simplification + conditional-state-scoping + O(1) lookups. Three orthogonal moves: (1) Dedicated per-view components replace thin wrappers shared between split/unified views — some code duplication traded for less per-line overhead (8 → 2 components per diff line); (2) Comment / context-menu state moved into conditionally-rendered child components, so the main diff-line component's only responsibility is rendering code (Single-Responsibility Principle framing) — state only exists where it's used, not multiplied by every line that could have state; (3) Single top-level event handler + data-attribute dispatch replaces per-line mouse handlers — the top-level handler inspects data-attribute values to determine which lines to affect (e.g. click-drag line selection). (Source: article § Small changes make a large impact)

  • O(1) state-map access + strict useEffect budget. v1 had "O(n) lookups across shared data stores and component state" plus extra re-rendering from useEffect scattered through the component tree. Fix: useEffect restricted to top-level of diff files, enforced with ESLint rules preventing new useEffect hooks in line-wrapping components (enables accurate memoization of diff-line components); global + diff state machines redesigned around JavaScript Map for O(1) lookups. Example shape: commentsMap['path/to/file.tsx']['L8'] returns whether line 8 has comments — passing file path + line number is all a diff line needs to check, no search over arrays. (Source: article § O(1) data access and less "useEffect" hooks)

  • v2 measured impact on a 10,000-line split-diff PR. Concrete numbers from the article's comparison table:

Metric v1 v2 Improvement
Total lines of code 2,800 2,000 27 % less
Unique component types 19 10 47 % fewer
Components rendered ~183,504 ~50,004 74 % fewer
DOM nodes ~200,000 ~180,000 10 % fewer
Memory usage ~150-250 MB ~80-120 MB ~50 % less
INP (m1 MBP, 4× slowdown) ~450 ms ~100 ms ~78 % faster

Note: component-count drop (74 %) and memory drop (50 %) dominate over DOM-node drop (10 %) — most of the win is in the React runtime layer, not the DOM. (Source: article § Did it work?)

  • TanStack Virtual for p95+ (giant) pull requests. "When you're working with massive pull requests — p95+ (those with over 10,000 diff lines and surrounding context lines) — the usual performance tricks just don't cut it. Even the most efficient components will struggle if we try to render tens of thousands of them at once." Integration with TanStack Virtual keeps only the visible diff-list window in the DOM; off-screen elements are swapped in on scroll. Reported impact on p95+ PRs: 10× reduction in JS heap usage + 10× reduction in DOM nodes; INP 275-700+ ms → 40-80 ms. (Source: article § Virtualization)

  • Server-side hydrate-visible-only + progressive loading cut time-to-interactive. "On the server side, we optimized rendering to hydrate only visible diff lines. This slashed our time-to- interactive and keeps memory usage in check." Plus progressive diff loading + smart background fetches so users can interact with what's already streamed, rather than waiting for every diff to arrive. Structurally mirrors the client-side virtualization choice at the hydration layer. (Source: article § Further performance optimizations)

  • Datadog-based interaction-level INP tracking + PR-size segmentation + memory tagging. Full-stack observability was rebuilt alongside the performance work: per-interaction INP measurements, metrics segmented by PR diff-size buckets, and memory tagging — all surfaced in a Datadog dashboard giving "real-time, actionable metrics to spot and squash bottlenecks before they become issues." The segmentation is load-bearing: without bucketing by PR size, tail regressions on p95+ PRs would be hidden under healthy-looking medians. (Source: article § Further performance optimizations)

  • CSS / layout-cost reductions. Heavy CSS selectors (e.g. :has(...)) swapped for cheaper alternatives; drag and resize handling re-engineered with GPU transforms, eliminating forced layouts / layout thrash during interactive operations. Each item is small but compounds across every diff-line rendering pass. (Source: article § Further performance optimizations)

Systems, concepts, patterns extracted

Numbers / scale anchors

  • 1 GB JavaScript heap on extreme-tail PRs (pre-optimization).
  • 400,000+ DOM nodes on extreme-tail PRs (pre-optimization).
  • 10,000-line split diff as the published benchmark workload.
  • ~450 ms → ~100 ms INP (v1 → v2) on m1 MBP with 4× CPU slowdown.
  • ~183,504 → ~50,004 React components rendered (74 % fewer) on the 10,000-line split-diff benchmark.
  • ~200,000 → ~180,000 DOM nodes (v1 → v2; 10 % — DOM-layer work is relatively fixed, React-layer work dominated the savings).
  • 150-250 MB → 80-120 MB memory (~50 % less).
  • 275-700+ ms → 40-80 ms INP for p95+ PRs after virtualization.
  • 10× reduction in JS heap + DOM nodes for p95+ PRs under virtualization.
  • v1 per-diff-line: ≥10 DOM / ≥8 React components / 20+ event handlers (unified); ≥15 DOM / ≥13 components (split).
  • v2 per-diff-line: 2 React components (dedicated per-view).

Caveats / what's not disclosed

  • No fleet-scale numbers. The benchmark is one 10,000-line split-diff PR on one m1 MBP with 4× slowdown — not an aggregate fleet p50/p99 across GitHub's user base. The virtualization-phase claims ("10× reduction", "275-700+ → 40-80 ms") are similarly illustrative rather than a distribution across real PR traffic.
  • No p50/p99/p999 shape across PR-size buckets. The Datadog dashboard is described as doing this segmentation but no bucketed numbers are published.
  • Virtualization's find-in-page trade-off is acknowledged, not quantified. The strategy section notes "Medium and large reviews stay fast without sacrificing expected behavior, like native find- in-page" — implying virtualization does sacrifice it on p95+ PRs. No detail on how GitHub UX-handles that (fallback search UI? scroll-to-match?).
  • No server-side infrastructure detail. The "hydrate only visible diff lines" + "progressive diff loading and smart background fetches" are described at the behavior level — no detail on the server-side-rendering substrate (React 18 streaming SSR? classic hydration pipeline? custom diff-chunk endpoint?), no latency numbers for the hydration phase, no disclosure of which diff-data store is behind the streaming.
  • No memory-profile shape. The 1 GB → <500 MB improvement is reported as "memory usage" in aggregate; no breakdown of DOM vs V8 heap vs Chromium process RSS, no comparison of peak vs steady-state.
  • No absolute fleet size / QPS. GitHub doesn't publish how many PR views/day are affected, how many hit the p95+ virtualization path, or what the infrastructure cost delta is.
  • No rollout discipline detail. "Now the default experience for all users" as the punchline — no staged-rollout / flag-gating / dark-ship-style comparison methodology disclosed, unlike the 2025 GitHub Issues-search rewrite which documented all three validation layers.
  • Not comparable to most ingested wiki sources on distributed-systems axes (no storage, streaming, networking, consistency, observability-of-backend, reliability, API-design content) — this is front-end performance engineering at scale. It passes the wiki's scope filter on the "performance / observability at scale" seam alongside the Atlassian streaming-SSR (2026-04-16) and Figma dynamic-page-loading (2024-05-22) ingests, not on the main distributed-systems axis. Cross-links reflect that narrow framing.

Raw source

raw/github/2026-04-03-the-uphill-climb-of-making-diff-lines-performant-45cd5b96.md

Source

Last updated · 200 distilled / 1,178 read