A pull's files page names its diff stretches and draws a 170 KB diff under 30 ms #6207

The Files page now reports where a cold diff phase spent its time. I added no new speed-up, because the slowest stretch was already cached.

What changed

• On a cache miss, Server-Timing carries diff-git, diff-parse and diff-highlight after diff. diff-git covers merge-base and git diff, diff-parse is our unified-diff parser, and diff-highlight is the whole-blob highlighting plus reading each blob.
• A hit names none of them, because it does no git, parsing or highlighting.
• To measure these, diffRange and diffBetween take an optional laps argument. Neither call's result changes, so line numbering and review anchors are identical.
• test/pull-files-stretches.test.ts builds a 20-file, 3,000-line diff and puts a review comment on m7.ts line 100. It asserts the three stretches on the first request and diff under 30 ms on the second. It also asserts the comment renders right after line 100, before line 101 and after line 99.
• test/pull-timing.test.ts expected the exact phase order, so I updated its expected list to include the three new phases. The old list was wrong now, not the code.

Which stretch is slowest

• Parse and highlight are already cached by (base oid, head oid) in diff-cache.ts. A second request is a lookup, and the rendered markup is cached too when no thread is drawn.
• The 97.8 ms in the issue was therefore a cold request. The new stretches show which part of a cold request is slow, but I didn't measure it on production.
• I did not limit highlighting to the hunks drawn. Highlighting whole blobs keeps tokens correct across hunk boundaries.

Checks run

• The new test, pull-files-cache, pull-files-speed, pull-timing, server-timing-sweep and route-timing-coverage all pass.
• bun x tsc --noEmit could not run in the sandbox: it reports that the bun type definitions are missing. The forge's check will run it.

Try it Open /<owner>/<repo>/pulls/N/files on a head not yet seen, and read the Server-Timing header.

Closes #6203

The Files page now reports where a cold diff phase spent its time. I added no new speed-up, because the slowest stretch was already cached.

What changed

• On a cache miss, Server-Timing carries diff-git, diff-parse and diff-highlight after diff. diff-git covers merge-base and git diff, diff-parse is our unified-diff parser, and diff-highlight is the whole-blob highlighting plus reading each blob.
• A hit names none of them, because it does no git, parsing or highlighting.
• To measure these, diffRange and diffBetween take an optional laps argument. Neither call's result changes, so line numbering and review anchors are identical.
• test/pull-files-stretches.test.ts builds a 20-file, 3,000-line diff and puts a review comment on m7.ts line 100. It asserts the three stretches on the first request and diff under 30 ms on the second. It also asserts the comment renders right after line 100, before line 101 and after line 99.
• test/pull-timing.test.ts expected the exact phase order, so I updated its expected list to include the three new phases. The old list was wrong now, not the code.

Which stretch is slowest

• Parse and highlight are already cached by (base oid, head oid) in diff-cache.ts. A second request is a lookup, and the rendered markup is cached too when no thread is drawn.
• The 97.8 ms in the issue was therefore a cold request. The new stretches show which part of a cold request is slow, but I didn't measure it on production.
• I did not limit highlighting to the hunks drawn. Highlighting whole blobs keeps tokens correct across hunk boundaries.

Checks run

• The new test, pull-files-cache, pull-files-speed, pull-timing, server-timing-sweep and route-timing-coverage all pass.
• bun x tsc --noEmit could not run in the sandbox: it reports that the bun type definitions are missing. The forge's check will run it.

Try it Open /<owner>/<repo>/pulls/N/files on a head not yet seen, and read the Server-Timing header.