GitHub mounts about 100 rows of a million-line diff by knowing every height before paint

You cannot put a million DOM nodes on a page ^[20]. Virtualization mounts the rows on screen plus a small margin, recycles those same elements as the reader scrolls, and lets the scrollbar behave as though all million rows exist ^[6]. Something has to supply the geometry for that illusion. The scrollbar height is the total of every row height, and row N sits at the total of the heights above it. Scrolling to a row and deciding what is visible are both lookups into one table of heights ^[7].

GitHub computes that table once and never corrects it, because a row of code at a known font size has a height you can know before anything paints ^[9]. The table lives in typed arrays, alongside an imperative recycled row renderer with no React component per row ^[10]. No per-frame work grows with the total row count ^[11]. On the test pull request, roughly 100 rows are real at a time ^[6], about one in ten thousand of the changed lines ^[16].

The post carries the byline of a Principal Design Engineer, and most of its design content is about offset tables and measurement ^[18]. A review thread only gets a height when it renders. Its size depends on how the markdown wraps at the current width, on details blocks the reader can expand in place, on a reply composer that opens inside the existing thread and grows as you type, and on images that change height when they finish loading ^[5][17]. GitHub's post says "Comments are the hard part." ^[4]

The condition for the fast path is narrow, and the post states it: every row is a line of code at a known font size ^[9]. Turn on soft wrapping for long lines and height becomes a function of width, which is the first item on GitHub's own list of why a comment cannot be measured in advance ^[5]. General-purpose variable-height virtualizers already solve that case, less cheaply: they build the height table from estimates and correct it as rows get measured ^[8].

The same pull request averages at least about 450 changed lines per file across its 2,200 files ^[15]. Collapsing every file to a single header row would still leave 2,200 rows, and opening one of them brings back hundreds ^[2].

On why the diff is enormous at all, the post credits stacked pull requests with making reviews easier and helping teams ship with less risk. Broad refactors and migrations, it says, often have to land as one change ^[13]. The renderer exists for the change that cannot be split cleanly ^[13].

Failures in this class surface under load, on a specific engine, at a specific scroll position. GitHub defined what healthy meant, instrumented the surface to answer it, and ran the change, measure, improve loop unattended ^[14]. The post also treats the feed as part of the problem: a fast diff surface is worthless if the data pipeline behind it stalls or throws away work it already did ^[19].