Какой Object pool стоит использовать в Rust?

Question

[Eugene Usachev]

Я изучаю Rust относительно недолго и начал изучать, как работать с сетью в Rust. И вот передо мной есть условный код (взятый из почти любой документации к почти любому фреймворку)

#[inline(always)]
fn handle_client(mut stream: TcpStream) {
    let mut buffer = [0; 1024];
    while match stream.read(&mut buffer) {
        /* do something*/
    } {};
}

fn main() {
// some code
for stream in listener.incoming() {
    match stream {
        Ok(stream) => {
            thread::spawn(move || {
                handle_client(stream)
            });
        }
        Err(e) => {/* do something*/}
    }
//some code
}

И меня очень смущает постоянно выделять буффер. Хотелось бы использовать некий пул буфферов.
Я долгое время разрабатывал на Go. Go имеет встроенную реализацию Object pool - sync.Pool, но вот Rust такой не имеет (или я плохо искал). Вместо этого я наткнулся на огромное количество реализаций Object pool пользователями github. Какой Object pool вы используете и почему?

Comments

[mayton2019]

У тебя чтение из стрима будет тысячекратно медлненее аллокации пула. Я так думаю. Может пример - неудачный.

Вот где реально пул нужен так это при работе с сокетными соединениями к БД.

[Eugene Usachev]

mayton2019, возможно, вы правы. Но мне просто "глаза режет" этот код. Хочется сделать по-хорошему, раз сроки не жмут.

[mayton2019]

Пиши боевой код и тестируй с профайлером. Потому что такие улучшизмы - только портят проект.
Я по себе знаю. Я тоже люблю пооптимизировать на пустом месте но вовремя бью себя по рукам
чтоб ничего такого не делать.

[Eugene Usachev]

mayton2019, я неопытный разработчик, так что не сочтите за грубость, но почему писать сразу оптимизированный код хуже, чем ждать, пока он начнёт тормозить?

[Василий Банников]

Eugene-Usachev, потому что есть такой код, который никогда тормозить не начнёт.
Оптимизировать заранее нужно только то, что ты заранее знаешь, что будет тормозить (например если знаешь, какая у тебя будет нагрузка и примерно посчитал)

[mayton2019]

Eugene-Usachev,

я неопытный разработчик, так что не сочтите за грубость, но почему писать сразу оптимизированный код хуже, чем ждать, пока он начнёт тормозить?

поскольку ты - неопытный разработчик - твои предсказания относительно оптимизированного кода базируются
не на личном опыте а на различного рода статьях, блогах, видосах и так далее. Все эти статьи нужно
проверять и протаскивать через практическоге доказательство правоты. Грубо говоря - ставить эксперимент
как в физике.

Я тебе предлагаю ПОСТАВИТЬ ЭКСПЕРИМЕНТ. Напиши две реализации кода. Как есть. И с пулом.
После этого приходи сюда с выводами.

[Eugene Usachev]

mayton2019, это было довольно грубо, тем более что мои предсказания относительно оптимизированного кода базируются на личном опыте оптимизации Go кода. Эксперимент я провёл и Вы оказались правы, разница настолько маленькая, что даже не понятно был ли выигрыш в скорости, что меня удивляет.

[mayton2019]

Eugene-Usachev, аллокация массива на стеке является вообще самой быстрой аллокацией в природе.
Это пожалуй справедливо для ассемблера и языков низкого уровня. Как в Rust и Go - я не знаю.
Там есть нюансы. Надо читать документацию и уже прочитав - тестировать performance.

Кстати написать хороший тест - очень большое искусство.

[Eugene Usachev]

mayton2019, мне самому стыдно. В Go все срезы аллоцируются в кучу, так что я даже не думал, что может быть по-другому.

[Василий Банников]

Eugene-Usachev, если смотреть на аналог срезов из Go, то это std::Vec будет. Ну и ещё есть read-only срезы &[].

По идее ещё в Go есть массивы фиксированной длины, которые могут тоже только на стеке выделяться (не уверен)

Answer 1

[Дмитрий Беляев]

меня очень смущает постоянно выделять буффер

Конкретно в данном примере буффер выделяется на стеке, то есть на его выделение не тратится ровным счетом ничего, так как стек и так уже выделен при запуске потока.
Есть конечно копеечные затраты ресурсов на заполнение буфера нулями. И если в буффер гарантированно сначала идет запись, как в данном случае, то это в принципе можно обойти:

use std::mem::MaybeUninit;
let mut buffer = unsafe {
    #[allow(invalid_value)]
    MaybeUninit::<[_; 1024]>::uninit().assume_init()
};

Но я бы так не делал. Во-первых чистота кода не стоит этих копеек производительности, а во-вторых немного накосячите с чтением и будет UB.

Comments

[Eugene Usachev]

Дмитрий Беляев, даже стыдно за то, что допустил такую ошибку в вопросе. Получается все массивы выделяются на стеке или есть предел длины? А векторы или срезы будут тоже выделяется на стеке?

[Василий Банников]

Eugene-Usachev, вектор выделяется в куче

[Дмитрий Беляев]

Eugene-Usachev, статические массивы выделяются на стеке если просто записать его в переменную, хотя можно и на куче разместить, если завернуть его в Box или Arc.
Теоретически предел - isize::MAX, на деле все упирается в наличии памяти на девайсе (для кучи и static переменных) или размер стека, если массив на стеке (для главного потока размер стека определяет ОС, для дочерних можно настраивать, по умолчанию 2МБ).
Правда с кучей есть нюанс, когда мы делаем Box::new(value) value сначала будет на стеке и потом переместится на кучу, так что тут опять упираемся в размер стека, хотя это обходится через unsafe и работу с аллокатором.
Ну а вектор - это динамический массив (с динамическим размером), такие возможны только на куче.

Answer 2

[Василий Банников]

Например https://crates.io/crates/deadpool

Но конкретно в твоём примере не вижу нужды в пуле буферов.

Comments

[Eugene Usachev]

Василий Банников, я честно только начал изучать Rust. Вам опытным разработчикам легко так говорить. Я долгое время работал с Go и даже писал свою http-либу. Именно с помощью Object pool для двух буферов (на запись и чтение) она обгоняла fasthttp (который тоже использует Object pool для тех же целей). Так что с моей точки зрения использование Object pool здесь должно быть оправдано, почему это не так?

для @vabka

(не успел протестировать deadpool сегодня, так что смогу отметить решением только завтра)

[Василий Банников]

Eugene-Usachev,

она обгоняла fasthttp

И почему забросили?

А ещё мне интересно, каким образом у вас получилась корректная и полная реализация http, которая при этом превосходила по производительности fasthttp, если у вас всего пару месяцев назад были вопросы уровня "как тестировать сетевые запросы" и "как структурировать проект"

[Eugene Usachev]

Василий Банников, Ну раз интересно, отвечу. За эти пару месяцев я и написал свою библиотеку. Забросил я её по причине того, что написал её. Мне не было интересно врываться в интернет с новой библиотекой, мне было интересно посмотреть, как работают сетевые библиотеки под капотом, я считаю, что я понимаю только то, что могу сам создать, поэтому и писал свою библиотеку, хотя мой самый большой проект всё ещё работает поверх fasthttp, так как там ну очень много переписывать : ).

[Василий Банников]

Eugene-Usachev, а исходники опубликованы?

[Eugene Usachev]

Василий Банников,

Мне не было интересно врываться в интернет с новой библиотекой

[Василий Банников]

Eugene-Usachev, тогда я бы не стал делать таких смелых заявлений