Разбор 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
Похожее
28.09.2026
C на Go
Интересный пропозал - добавить возможность сборки Go-пакетов, использующих cgo д...
25.09.2026
Бенчим джейсон
Автор на реальном API с нагрузкой 50M запросов/сутки)сравнивает производительнос...
24.09.2026
Rune
Команда Unstable Build заопенсорсила свою нативную IDE Rune, написанную на Go. ...
23.09.2026
Специализированные аллокаторы
В Go 1.27 появилась оптимизация выделения памяти для объектов размером до 80 бай...