Разбор zero-copy-оптимизаций в Go.
Когда вы передаете `*os.File` напрямую `в io.Copy(conn, f)`, рантайм распознает это через цепочку type-assertions и вызывает `sendfile(2)`, передавая данные из кеша странички в сокет без копирования в юзерспейсе. Но вот когда вы оборачиваете `*os.File` в свой собственный `io.Reader`, то все становится не так радужно. В тестах использование `*os.File` дает прирост в ~54 мс CPU на гигабайт и ~3 000 сисколлов против 184 мс CPU и 131 000 сисколлов при оборачивании файла в любой пользовательский io.Reader. Единственная "бесплатная" обертка это `io.LimitedReader`, которую рантайм явно разворачивает.
Для проксирования сокет-в-сокет та же логика работает через `splice(2)`, но любая промежуточная обертка ломает fast path, и диагностировать это проще всего через `strace -c`. Сотни тысяч пар read/write означают, что zero-copy не работает в вашем коде
08.07.2026
Похожее
19.07.2026
Объединение запросов
Статья объясняет технику объединения запросов на Go с помощью пакета singlefligh...
16.07.2026
mmap или pread
Автор статьи - инженер из VictoriaMetrics. На примере реального движка хранения ...
16.07.2026
TypeScript переписали на Go
Команда Microsoft с помощью AI переписала компилятор TypeScript 7.0 на Go, а не ...
14.07.2026
На 49% быстрее из-за выравнивания
Разбор неожиданной оптимизации в Go: сдвиг массива на 4 байта через добавление p...