# Measurement: the wire level baseline

- Date: 2026-09-22
- Machine: AMD Ryzen AI Max+ Pro 395 (32 threads), idle
- Toolchain: go1.27.1, no build flags
- Command: `go test ./internal/nfs4server/ -run '^$' -bench=Wire -benchmem -count=5`

## Baseline

The commit 354760b, the head of development: the wire benchmarks are new, so this
report is the baseline every later optimisation of the request path measures
against. One benchmark iteration is one COMPOUND of the client library against
the server handler over a loopback connection, sessions included.

## Result

Median of five runs, same session, same machine.

| Benchmark | Throughput | Latency | Allocations |
|---|---|---|---|
| `BenchmarkWireRead64K` | 805 MB/s | 81.4 µs/op | 78 allocs, 628 KiB/op |
| `BenchmarkWireWrite64K` | 1062 MB/s | 61.7 µs/op | 76 allocs, 428 KiB/op |
| `BenchmarkWireGetattr` | - | 14.2 µs/op | 85 allocs, 4.1 KiB/op |
| `BenchmarkWireLookup` | - | 15.0 µs/op | 81 allocs, 4.4 KiB/op |

READ of a 64 KiB chunk is slower than WRITE of the same chunk, and the
allocation columns show where the request path spends its memory: around 80
allocations per COMPOUND regardless of the operation, on top of the data copies
the read and write paths make. Both facts are the starting point for the
optimisations of the request path; neither is a claim about any other setup.