Measure the batched read: 184 frames to 12 at twenty thousand files

The fixture was rebuilt and kept this time, and the same benchmark run against it with only the listing changed. Twenty thousand files: min 166 to 10 frames, median 184 to 12, max 598 to 48. Ten to twelve frames is 0.17-0.20 s, inside the range where an interaction reads as instant, against roughly three seconds before, and the outlier fell by a factor of twelve.

The doc is careful about what that measures: the test waits for file-0.txt, which is in the first batch, so those frames are time-to-first-rows. The other nineteen batches still take the ~2 s of readdir and stat described above - they simply arrive behind the progress bar, into a list the user is already scrolling. Both halves matter and only the first is in the table.

It also records the fixture policy that made this possible: --count reuses a folder that already holds at least that many files and --fresh rebuilds, because building twenty thousand files costs half an hour on this phone. Keeping it was the lesson I wrote down and then failed to follow twice.

docs/PERFORMANCE.md

@@ -182,6 +182,32 @@ beat are the ones in the table above and the first thing to do with that fixture
 `openAFolderOfAThousandFiles` and look at the *min* iteration rather than the median — the minimum is what
 "first rows visible" now governs.
 
+### Measured: the batched read
+
+The fixture was rebuilt and the same benchmark run against it, on the same phone, with only the listing
+changed:
+
+| 20 000 files, `openAFolderOfAThousandFiles` | one batch | 200-entry batches |
+|---|---|---|
+| min | 166 frames | **10** |
+| median | 184 frames | **12** |
+| max | 598 frames | **48** |
+
+**Ten to twelve frames is about 0.17–0.20 s** — inside the range where an interaction reads as instant —
+against roughly three seconds before, and the outlier fell from 598 to 48. The change is a factor of
+fifteen on the median and it costs nothing: the same reads happen, the same `stat`s, they are simply
+delivered as they complete instead of after the last one.
+
+What that number is *not*: the time to *use* the whole folder. The first batch is what the test's wait sees
+(`file-0.txt` is inside it), so these frames measure "first rows on screen". The remaining nineteen-odd
+batches still take the ~2 s described above — they arrive behind the progress bar, into a list the user is
+already scrolling rather than into an empty screen. Both halves matter, and only the first one is in this
+table.
+
+And the fixture now survives: `tools/benchmark-fixture.sh --count 20000` reuses a folder that already holds
+at least that many files, and `--fresh` rebuilds it. Building it takes about half an hour through MIUI's
+storage layer, which is the whole reason to keep it.
+
 Building that fixture is the expensive part, not measuring it: 20 000 files took about thirty minutes
 through MIUI's storage layer (`: >` in a loop), against roughly four minutes of benchmark on top. Worth
 knowing before anyone re-creates it, and an argument for the fixture being built once and kept.