Inside GitHub's million-line pull request renderer

GitHub Engineering describes rebuilding the Copilot app's pull request view for unusually large changes. Their stress case contained 2,200 files, more than a million changed lines, and over 400 inline comments.

The article follows the performance work behind a responsive diff: instrumenting renders, testing scrolling and resizing, and checking the experience in the actual desktop app. It is a concrete look at UI engineering under extreme data volume.

A real stress case

The engineering post uses an actual open-source pull request with 2,200 files, more than a million changed lines, and over 400 comments. That is far beyond the pull request most teams see, which makes it a useful test of assumptions about scrolling, expansion, and comment rendering. The product must support review in its Files changed view, not merely load a summary page.

GitHub describes two validation lanes: a headless probe that tracks render counts, performance timing, and frame smoothness; and an automated run through the real desktop app with cold and warm comment states. The distinction matters. A synthetic benchmark can show regressions quickly, while the real workflow catches awkward interactions a number cannot describe.

A useful pattern for any large UI

Measure the expensive state transitions, not just first paint. Open details, resize the window, move deep into a file list, then return to comments. React's Profiler documentation explains how to count component render work; it is one instrument, not the whole performance story. The lesson here is to make the worst realistic user journey part of the test suite before someone arrives with the million-line PR.

Sources and further reading

• Original publication
• GitHub Docs: reviewing pull requests in the app
• React: measuring render performance