A byte-counting http.ResponseWriter wrapper made io.Copy of a large file to the client slower. Why?

## What the fast path was `io.Copy(dst, src)` is not a plain loop. Before allocating anything it asks two questions: 1. Does `src` implement `io.WriterTo`? If so, call `src.WriteTo(dst)`. 2. Does `dst` implement `io.ReaderFrom`? If so, call `dst.ReadFrom(src)`. Only if both fail does it allocate a 32 KiB buffer and loop `Read` into it, then `Write` out of it. `net/http`'s response writer implements `io.ReaderFrom`. Under the right conditions — an ordinary HTTP/1 body with no compression or chunk-rewriting layer in between, and an `*os.File` on the reading side — that path can hand the copy to the connection itself and let the operating system move the bytes without ever bringing them into the process. Even when it cannot, delegating to the writer's own `ReadFrom` avoids the extra buffer and the extra pair of copies per chunk. This is not an exotic path: `http.ServeContent` and `http.ServeFile` copy through it, so any endpoint serving files or large payloads is on it by default. ## What the wrapper did A recording wrapper embeds the `http.ResponseWriter` interface, which promotes exactly `Header`, `Write` and `WriteHeader`. The wrapper does not implement `io.ReaderFrom`, so step 2 above now fails and `io.Copy` takes the slow branch. Per response you gain a 32 KiB allocation, a read syscall and a write syscall per chunk, and a full user-space copy of every byte. On a hot large-file endpoint that turns up as higher CPU per byte and a jump in `B/op` and `allocs/op` under `go test -bench . -benchmem`, or as `syscall.Write` and memory-move frames dominating a CPU profile taken with `go tool pprof`. The reason it is hard to notice is that nothing failed. The bytes are correct, the status is correct, the tests pass. Only the throughput of one class of endpoint changed, and the change arrived with a middleware whose stated purpose was to count bytes. ## The fix Give the wrapper a `ReadFrom` so its own type satisfies `io.ReaderFrom` again: ```go func (r *recorder) ReadFrom(src io.Reader) (int64, error) { if rf, ok := r.ResponseWriter.(io.ReaderFrom); ok { n, err := rf.ReadFrom(src) r.nbytes += n return n, err } n, err := io.Copy(r.ResponseWriter, src) r.nbytes += n return n, err } ``` Three details matter: - **Add the returned `n` to the counter.** This is the bug that hides inside the fix: once `ReadFrom` exists, body bytes no longer flow through your `Write` override, so a wrapper that forwards `ReadFrom` without counting will log large responses as zero bytes — the same class of wrong-number defect as recording status 0. - **Fall back with `io.Copy` on the wrapped writer, not on the wrapper.** Passing `r` back into `io.Copy` would re-enter your own `ReadFrom` and recurse. - **Remember the implicit status.** The delegated write triggers `net/http`'s implicit 200 without calling your `WriteHeader` override, so the wrapper still needs a sane initial status. ## What does not fix it `http.ResponseController` is the standard answer for lost capabilities, but its surface is `Flush`, `Hijack` and the read and write deadlines. There is no `ReadFrom` on it, and adding `Unwrap` to your wrapper does not change the wrapper's own method set, so `io.Copy` still sees only an `io.Writer`. This is one of the few capabilities you genuinely have to forward by declaring the method. Making your own `Write` use a bigger buffer does not help either — the buffer belongs to `io.Copy`, not to you — and setting `Content-Length` changes framing, not the copy strategy. ## Is it worth doing? Measure before you decide. For an API serving small JSON bodies, the `ReadFrom` path is irrelevant and the extra method is noise. For a service that streams files, media or large exports, the difference is real and it is exactly the kind of regression that gets attributed to "the new observability layer" without anyone being able to say why. Because the wrapper is shared, the cost of forwarding `ReadFrom` is paid once and every endpoint keeps its original throughput — which is the general argument for putting careful, well-tested wrapping in one library rather than in each service.