Post Thumbnail

Разбор 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 не работает в вашем коде

Похожее

Post Thumbnail

WAL-RUS

ClickHouse Cloud переписали утилиту для бэкапов и WAL-архивирования Postgres с G...