Разбор 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
Похожее
07.07.2026
WAL-RUS
ClickHouse Cloud переписали утилиту для бэкапов и WAL-архивирования Postgres с G...
06.07.2026
Профилирование
Статья разбирает пять встроенных профилировщиков в Go (CPU, heap, block, mutex и...
02.07.2026
6 популярных кешей
Автор сравнивает шесть подходов к реализации потокобезопасного in-memory кеша в ...
29.06.2026
Детектор утечек горутин
В Go 1.27 в runtime/pprof добавляется встроенный детектор утечек горутин, принят...