🦀 Десериализация в Rust 🦀

Тоже производительная, как и все остальное в Rust. Все потому, что она zero-copy.

Рассмотрим подробнее 🤨

При работе с большими JSON или бинарными данными традиционная десериализация создаёт копии строк и байтов. Это естественно расходует память. 💀
Система владения в Rust позволяет использовать мощную оптимизацию: zero-copy десериализацию.

Проблема:

// Обычная десериализация - создаёт owned String
#[derive(Deserialize)]
struct User {
    name: String,  // Выделяет новую память
    email: String, // Ещё одна аллокация
}

// При парсинге JSON каждая строка копируется в кучу
let json = r#"{"name": "Иван", "email": "ivan@example.com"}"#;
let user: User = serde_json::from_str(json)?;
// Данные скопированы из json в user.name и user.email

Решение:

// Zero-copy с заимствованными данными
#[derive(Deserialize)]
struct User<'a> {
    #[serde(borrow)]
    name: &'a str,  // Без аллокации!
    #[serde(borrow)]
    email: &'a str,
}

// Теперь данные НЕ копируются
let json = r#"{"name": "Иван", "email": "ivan@example.com"}"#;
let user: User = serde_json::from_str(json)?;
// user.name и user.email просто ссылаются на части json!

Преимущества очевидны 💡:

• Производительность: Устраняем аллокации для строковых/байтовых полей
• Эффективность памяти: Ссылаемся на оригинальный буфер вместо копирования
• Низкие задержки: Критично для высоконагруженных сервисов

⚠️ Но всегда стоит помнить!
Заимствованные данные должны жить дольше вашей структуры. Десериализованный объект не может пережить исходный буфер.

В сочетании с simd-json или похожими библиотеками можно достичь времени парсинга на уровне микросекунд.

Был ли у вас опыт с zero-copy в Rust? 🍷

🚀 Пост Guru Rust: @PaulEdd

🦀 СТАТИЧЕСКИЙ vs. ДИНАМИЧЕСКИЙ полиморфмизм 🦀

На собесах про это часто любят спрашивать. Давайте разберемся, в чем же разница между двумя этими понятиями.

В Rust есть два способа работать с трейтами - и они кардинально отличаются под капотом. 🤑

Статический полиморфизм (с использованием дженериков)

trait Animal {
    fn speak(&self);
}

struct Dog;
struct Cat;

impl Animal for Dog {
    fn speak(&self) { println!("Гав!"); }
}

impl Animal for Cat {
    fn speak(&self) { println!("Мяу!"); }
}

// Статический полиморфизм
fn make_speak<T: Animal>(animal: &T) {
    animal.speak();
}

Компилятор под капотом генерирует отдельную функцию для каждого типа. Это называется мономорфизацией.

// Компилятор создаёт две версии:
fn make_speak_Dog(animal: &Dog) { ... }
fn make_speak_Cat(animal: &Cat) { ... }

Динамический полиморфизм (с использованием трейт-объектов)

// Динамический полиморфизм
fn make_speak_dyn(animal: &dyn Animal) {
    animal.speak();
}

// Можно хранить разные типы в одной коллекции!
let animals: Vec<Box<dyn Animal>> = vec![
    Box::new(Dog),
    Box::new(Cat),
];

for animal in &animals {
    animal.speak();
}

Здесь компилятор создаёт одну функцию, а нужный метод ищется в рантайме через vtable (таблицу виртуальных методов).


Когда что использовать? 🤨

Статический полиморфизм:
- Максимальная производительность. Никаких накладных расходов в рантайме
- Компилятор знает конкретный тип
- Но: раздувает бинарник (код дублируется для каждого типа)

Динамический полиморфизм:
- Больше гибкость. Можно хранить разные типы в одной коллекции
- Меньше размер бинарника
- Но: косвенный вызов через vtable (небольшой оверхед)
- Но: нельзя использовать с не-object-safe трейтами

Что чаще используете - дженерики или трейт-объекты?

🚀 Пост Guru Rust: @PaulEdd

🦀 ПРОФИЛИРОВАНИЕ 🦀

Как найти, что тормозит в программе? 🧐

Интуиция нас часто обманывает. Кажется, что тормозит сложный алгоритм - а на деле проблема в лишних аллокациях или клонировании строк в цикле. Без конкретных измерений оптимизация превращается в лотерею: переписываешь код, который и так работал нормально, а реальное узкое место не трогаешь.

Профилирование позволяет посмотреть, какие участки кода тормозят или где в программе утечки памяти 🫥


Какие подходы существуют 🤑

1. Семплирование - профилировщик периодически «фотографирует» стек вызовов. Если функция часто попадает в выборку, значит в ней тратится много времени.
Этот подход почти не замедляет программу.

2. Второй подход. В код вставляются метки, в которых замеряется точное время входа-выхода. Распространено, потому что легко сделать с помощью логов.

3. Микробенчмарки. Изолированный замер конкретной функции. Можно использовать, к примеру, для сравнения двух реализаций.

4. Профилирование памяти. Где и сколько аллокаций. В Rust утечки редки, но лишние аллокации тормозят.


Инструменты профилирования ⛏

- perf + flamegraph - sampling-профилирование на Linux. Рисует наглядную картину: чем шире блок, тем больше времени в функции.

cargo install flamegraph
cargo flamegraph --bin myapp
# открываешь flamegraph.noscript в браузере

- criterion - микробенчмарки со статистикой. Сравниваешь две реализации и видишь, какая быстрее:

use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn bench(c: &mut Criterion) {
    c.bench_function("fib 20", |b| {
        b.iter(|| fibonacci(black_box(20)))
    });
}

criterion_group!(benches, bench);
criterion_main!(benches);

- tracing + tracy - для асинхронного кода. Показывает таймлайн: что выполнялось, что ждало, где блокировки.

- heaptrack / dhat - профилирование памяти. Находит, где программа просит память чаще всего.


Порядок действий 🤔

1. Убедись, что проблема есть - может, код уже достаточно быстрый
2. Собери профиль на реалистичных данных
3. Найди самое узкое место
4. Оптимизируй только его
5. Измерь снова
6. Повтори

Оптимизировать то, что занимает 2% времени - пустая трата сил.

Какие инструменты используете вы? Был случай, когда профилирование показало что-то неожиданное?🚬

🚀 Пост Guru Rust: @PaulEdd