Разбор 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
Похожее
22.08.2026
Время читать код
Автор утверждает, что главное узкое место разработки незаметно сместилось с напи...
21.08.2026
Go для Dreamcast
Я только на прошлой неделе публиковал пост, в котором искал инструмент для прогр...
20.08.2026
Батчинг
Статья показывает, как в Go аккуратно батчить данные, поступающие в реальном вре...
20.08.2026
KV на S3
Статья разбирает, как построить key-value базу данных, у которой основным слоем ...