# Luci performance

`internal/web/perf_test.go` benchmarks deterministic dashboard and run views.

Fixtures contain 120 runs × 2 children for `small`, 1,000 runs × 4 children for `medium`, one pending run, and one active child.

## Method

Build baseline and candidate test binaries from their respective source revisions.

Run each binary with `GOMAXPROCS=1`, `-run '^$'`, `-bench '^(BenchmarkBuildDashboard|BenchmarkBuildRun)$'`, `-benchtime=3s`, and `-count=1`.

Alternate binary order over 15 batches, appending each binary's output to separate files.

Compare files with `go tool benchstat baseline.txt candidate.txt`.

A standalone candidate measurement is runnable with:

```sh
GOMAXPROCS=1 go test ./internal/web -run '^$' -bench '^(BenchmarkBuildDashboard|BenchmarkBuildRun)$' -benchtime=3s -count=15 > target/luci-perf/candidate.txt
go tool benchstat target/luci-perf/baseline.txt target/luci-perf/candidate.txt
```

Profiles use the same environment with one `medium` benchmark, `-benchtime=15s`, `-cpuprofile`, and `-memprofile`.

## 2026-09-27 short-ID result

Hardware: AMD Ryzen 5 5600X, 12 logical CPUs, 31 GiB RAM, CachyOS Linux 7.2.7-1-cachyos x86_64.

Runtime: Go 1.27.1-X:nodwarf5, `GOMAXPROCS=1`.

| benchmark | baseline median | candidate median | time change | p, n |
| --- | ---: | ---: | ---: | --- |
| dashboard/small | 18.279 ms ±2% | 0.509 ms ±2% | -97.21% | <0.001, 15 |
| dashboard/medium | 1,092.512 ms ±1% | 4.803 ms ±1% | -99.56% | <0.001, 15 |
| run/small | 18.099 ms ±1% | 0.247 ms ±1% | -98.64% | <0.001, 15 |
| run/medium | 1,099.809 ms ±2% | 2.306 ms ±1% | -99.79% | <0.001, 15 |

`benchstat` intervals are 95% confidence intervals.

Candidate timing coefficient of variation was 1.08-2.17% versus 1.28-3.46% for baseline.

Medium dashboard allocation changed from 177.081 MiB and 20.088M allocs/op to 3.749 MiB and 19.38k allocs/op.

Medium run allocation changed from 178,361.6 KiB and 20.074M allocs/op to 869.1 KiB and 5.240k allocs/op.

The change encodes each run ID once, counts usable proquint block prefixes once, and counts usable revision prefixes once.

This preserves aliases whose distinct input IDs parse to the same value, because every distinct ID still increments the shared rendered-prefix count.

Benchmarks cover in-memory view construction, not disk reads, Git access, log decompression, template rendering, HTTP latency, or CI job throughput.
No timing or allocation regression was detected in the four measured cases.
The initial baseline batch was slower than the alternating control, so reported comparisons use only the alternating batches.
Results are local measurements under ordinary machine load, not a cross-machine performance guarantee.