Let the benchmark fixture be any size, so the scaling question can be asked

count is now a parameter: ./tools/benchmark-fixture.sh --count 20000 builds the folder the performance doc has been promising 5000 and 20000-file numbers for. The script validates the argument rather than quietly building the default folder, which is the failure mode that would otherwise waste a run. Verified with 1500 files and then removed.

docs/PERFORMANCE.md

@@ -218,7 +218,7 @@ when a run ended, which is why the earlier numbers had to be copied mid-run.
 
 | number | status |
 |---|---|
-| Folder open with 5 000 / 20 000 files | not measured: the fixture script counts to 1 000 |
+| Folder open with 5 000 / 20 000 files | not measured yet: `./tools/benchmark-fixture.sh --count 20000` builds that fixture, and the open/scroll numbers follow from re-running the same command |
 | Thumbnail paint while scrolling a photo grid | not measured: no test for it yet |
 | Any jank figure at all | not measurable here: this phone's `FrameTimingMetric` output is `frameCount` only, with no `frameDurationCpuMs` or `frameOverrunMs` |
 

tools/benchmark-fixture.sh

@@ -19,6 +19,18 @@ package=de.softwareapp_hb.filemanager
 directory=/sdcard/AABenchmark
 count=1000
 
+# The size is a knob because the interesting question is how the browser scales: 1 000 files is what the
+# benchmark uses by default, and 5 000 or 20 000 is the same run with a bigger folder:
+#
+#   ./tools/benchmark-fixture.sh --count 20000
+if [ "${1:-}" = "--count" ]; then
+    count=${2:?"--count needs a number"}
+    case "$count" in
+        ''|*[!0-9]*) echo "benchmark-fixture: --count needs a number, not '$count'" >&2; exit 2 ;;
+    esac
+    shift 2
+fi
+
 case "${1:-create}" in
     --remove)
         adb shell "rm -rf $directory"