# Measurement: the descriptor cache in internal/nfsfs

- 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/nfsfs/ -run '^$' -bench=. -benchmem -count=5`

## Baseline

The commit b8758b7, the head of development before the descriptor cache: every
READ, WRITE and SYNC opened the registered path, verified it with a stat and
closed the descriptor again, per operation. The cache keeps idle descriptors of
regular files in a bounded LRU and revalidates the identity on every use, so the
measurements answer one question: what the open and close per operation cost.

## Result

Median of five runs, same session, same machine.

| Benchmark | Baseline | With cache | Change |
|---|---|---|---|
| `BenchmarkRead64K` | 10888 ns/op | 9047 ns/op | -16.9 % |
| `BenchmarkWrite64K` | 5881 ns/op | 5236 ns/op | -11.0 % |
| `BenchmarkGetattr` | 461.4 ns/op | 437.2 ns/op | -5.2 % |
| `BenchmarkLookup` | 1216 ns/op | 1134 ns/op | -6.7 % |

The two data operations are the ones the cache touches, and they gain 11 to 17
percent per operation. GETATTR and LOOKUP run the same code as before the cache
(they resolve paths through Lstat either way), so their shifts are code layout
noise of the same binary, not an effect to claim; both sit within the run to run
spread the five repetitions showed.