Методика (шаги)
- Воспроизвести рабочую нагрузку в условиях, близких к боевым (входные данные, частота вызовов, аппарат).
- Собрать негрубую картину: CPU, память, I/O, латентность по p99/p95. Затем локализовать горячие участки с помощью семплингового профайлера.
- Использовать семплинг (малый оверхед) для поиска «горячих» функций, затем при необходимости детализировать трассировками/инструментацией для конкретных участков.
- Сравнивать до/после по тем же сценариям и метрикам (средняя задержка, p95/p99, пропускная способность, CPU%).
- Фиксировать изменения и регресс-тестировать (корректность, многопоточность, утечки).
Инструменты и сбор данных
- Linux perf: `perf record --call-graph=dwarf` / `perf report` для семплинга + счётчики (cache-misses, branch-misses).
- FlameGraph (Brendan Gregg) для визуализации стека из `perf`/`perf script`.
- Intel VTune / AMD uProf — для детального профайлинга, hotspot/ITT.
- eBPF-подходы (bcc, bpftrace) для низкооверхедного трассинга в проде.
- Valgrind (масштабно тяжёл), Cachegrind для симуляции кэша; Massif/heaptrack/Dr. Memory для аллокаций.
- Sanitizers (ASan/TSan) для ошибок памяти и гонок.
- Allocation tracers: tcmalloc/hoard/jemalloc профайлеры, heaptrack.
- LTTng/ftrace/trace-cmd для системного трассинга (syscall, wakeups, sched).
- Простые метрики: `perf stat` (instructions, cycles, cache-misses), iostat, vmstat, top/htop.
Типичные причины тормозов
- Кэш-промахи (L1/L2/L3) из-за неудачной размещённости данных или плохой локальности.
- Частые динамические аллокации/деаллокации (malloc/free) и фрагментация.
- Синхронизация: блокировки, ожидания, false sharing.
- Системные вызовы и контекстные переключения (I/O, blocking waits).
- Частые копирования больших структур (pass-by-value).
- Ветка-предсказание: частые mispredicts из-за непредсказуемых ветвей.
- Плохие структуры данных / неподходящий алгоритм (O(n^2) вместо O(n log n)).
- Вызовы виртуальных функций, интерпретация, heavy logging на hot-path.
- NUMA-ошибки (некорректное распределение памяти по узлам).
Конкретные приёмы оптимизации (что делать и когда)
1) Алгоритм прежде всего
- Заменить н²-алгоритм на более эффективный (скорость обычно выигрывает больше всех микрооптимизаций).
- Риск: низкий — корректность должна быть покрыта тестами.
2) Снижение аллокаций
- Использовать reserve/resize для std::vector; пул объектов; reuse buffers.
- Пример: заменить частые `new`/delete` на preallocated pool.
- Риск: низкий-средний (если пул управляется аккуратно).
3) Улучшение локальности данных (AoS -> SoA)
- Разбить массив структур на структуры массивов, если обрабатываете только отдельные поля подряд.
- Применимо для циклов, проходящих по одному полю.
- Риск: средний (изменяет API/структуры, требует тестов).
4) Уменьшение синхронизации
- Использовать per-thread буферы/очереди, read-copy-update, lock striping, уменьшение времени удержания мьютекса.
- Риск: средний-высокий (сложно и опасно для корректности, требует тестов).
5) Устранение false sharing
- Паддинг/alignas для разделения переменных, используемых разными потоками.
- Риск: низкий.
6) Снижение ветвлений / предсказуемые ветви
- Рефакторинг условий, таблицы переходов, branchless-версии.
- Риск: низкий-средний (проверить производительность и читаемость).
7) Использование SIMD/векторизации
- Автовекторизация компилятором или ручной SIMD (intrinsics).
- Риск: высокий (сложно и портируемость).
8) Inline, restrict, PGO, LTO, оптимизация компилятора
- Включить оптимизации: `-O3`, PGO и LTO.
- Риск: низкий (иногда изменения в поведении из-за переоптимизаций — регресс-тесты).
9) Предварительное чтение / prefetch
- Использовать префетчинг в критичных циклах.
- Риск: средний (может ухудшить, если неправильно).
Пример до/после (типичная реальная простая ситуация: частые аллокации и плохая локальность)
Сценарий: в цикле создаём и помещаем временные структуры в вектор; множество реаллоков и копирований.
До:
struct Particle {
double x, y, z;
double vx, vy, vz;
// тяжелые поля
};
void simulate_step(int N) {
std::vector buf;
for (int i = 0; i < N; ++i) {
Particle p = create_particle(i); // много временных аллокаций внутри
buf.push_back(p); // возможные реаллокации и копии
process(p);
}
}
После (оптимизации: reserve, emplace, reuse, SoA вариант для горячих полей):
// 1) Быстрая фиксация резервом и emplace
void simulate_step(int N) {
static std::vector buf;
buf.clear();
buf.reserve(N); // избегаем реаллокаций
for (int i = 0; i < N; ++i) {
buf.emplace_back(create_particle_inplace(i)); // строим прямо в векторе
process(buf.back());
}
}
// 2) Или SoA для лучшей кеш-локальности, если обрабатываем только позиции:
struct PartPos { std::vector x, y, z; };
void simulate_step_soa(int N) {
static PartPos pos;
pos.x.resize(N); pos.y.resize(N); pos.z.resize(N);
for (int i = 0; i < N; ++i) {
pos.x[i] = ...; // эффективные последовательные записи
}
}
Типичный измеренный эффект (пример): после `reserve` + emplace — время шага снизилось с $120\text{ms}$ до $40\text{ms}$ (примерно $\frac{120-40}{120}\times 100\%=66.7\%$ ускорения). Переход на SoA для горячего поля может дополнительно сократить кэш-промахи и снизить время до $30\text{ms}$.
Оценка риска по приёмам (кратко)
- Низкий риск: reserve/clear+reuse, убрать лишний лог, compiler flags, PGO, уменьшение syscalls.
- Средний риск: data-layout (AoS->SoA), padding/align, замена allocators, уменьшение синхронизации (нужны тесты).
- Высокий риск: lock-free, ручной SIMD/intrinsics, изменение порядка операций и memory model — возможны subtle баги.
Контроль качества
- Проводить A/B тесты, регрессионное тестирование, fuzzing для многопоточных изменений.
- Сохранять профайлы «до» и «после», проверять p95/p99 latencies, потребление памяти, число контекстных переключений и cache-misses (`perf stat`).
- Внедрять изменения пошагово: сначала низкорискованные, затем более сложные.
Короткий чек-лист при оптимизации «в реальном времени»
1. Измерил (baseline). 2. Локализовал hotspot семплингом. 3. Применил простые исправления (reserve, убрать лог). 4. Повторил измерения. 5. Если нужно — поменял data layout/синхронизацию. 6. Тесты на корректность и регресс. 7. Деплой с мониторингом.
Если нужно — могу предложить конкретные команды perf/eBPF для сбора trace в вашей среде и/или помочь профилировать конкретный участок кода (прислать фрагмент).