contrib/perf: use representative numbers for the decoration patchHEADmaster

The figures in the README came from a single render of linux.git's tip,
which is an unusually large merge, and from a box that still had load on
it from the previous benchmark. Re-measured on an idle machine over 60
random commits: 12.6 ms to 2.0 ms rather than 14.83 to 3.13.

Also note that the esi-diff fragment does not change, which is the point
worth knowing: fragments carry no subject line and so never ask for
decorations at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

1 files changed, 9 insertions, 3 deletions

diff --git a/contrib/perf/README b/contrib/perf/README
index c42a3d6..65a5653 100644
--- a/contrib/perf/README
+++ b/contrib/perf/README
@@ -31,9 +31,15 @@ of which 1008 annotated tags) and linux.git (946 refs, 945 tags, 3.7 GB pack).
     decoration key, so lookup_unknown_object() serves without asking the
     object store what it is.
 
-    Frame render, this box (i7-7700), cgit cache off:
-        linux.git   14.83 ms -> 3.13 ms   (946 refs, 945 tags, 3.7 GB pack)
-        git.git      6.49 ms -> 2.23 ms   (1017 refs, 164 MB pack)
+    Frame render on an idle i7-7700, cgit cache off, averaged over 60
+    random commits:
+        linux.git   12.6 ms -> 2.0 ms   (946 refs, 945 tags, 3.7 GB pack)
+        git.git      6.5 ms -> 2.2 ms   (1017 refs, 164 MB pack)
+
+    A control serving the same objects through a repository with one ref
+    instead of 946 costs 1.7 ms, so this closes most of what is left.
+    The esi-diff fragment is unaffected (25.4 ms either way): it has no
+    subject line, so it never asks for decorations.
 
     Output is byte-identical: git log --decorate over 20000 linux.git
     commits and all of git.git, for-each-ref and tag -l with peeled