Кратко и по делу — что собирать, чем профилировать и как решать, когда менять алгоритм, а когда не стоит.
1) Какие метрики собирать
- Время выполнения: суммарное wall‑time и CPU‑time (user/system). Включать процент времени в ожидании I/O/блокировках.
- Латентности: $p_{50},p_{95},p_{99}$ и максимум — для отклика сервисов.
- Пропускная способность: запросы/сек, операций/сек.
- Использование CPU: загрузка и использование по ядрам, контекст‑переключения, time spent in user vs kernel.
- Память: RSS, виртуальная память, текущий heap size, пиковые значения и скорость аллокаций (например, $B/s$).
- Аллокации: количество аллокаций/сек, размер аллокации, распределение по стеку (who allocates).
- GC/пауз: доля времени в GC и длительность пауз.
- Контенция: блокировки, очереди, ожидание синхронизации, false sharing.
- Микроархитектурные счётчики: кеш‑промахи, branch‑mispredicts, TLB misses (по необходимости).
- E2E метрики и ошибки: latency percentiles в реальной нагрузке, ошибки/таймауты.
2) Инструменты для CPU‑профайлинга
- Общие (Linux): perf (perf record/top), oprofile, FlameGraphs (Brendan Gregg) для визуализации.
- Инструменты с низким оверхедом: eBPF/BCC, bpftrace, async-profiler (Java), perf + stackcollapse.
- Языко‑специфичные: go tool pprof (Go), pprof/gperftools (C/C++), VisualVM/JFR/async‑profiler/YourKit/JProfiler (Java), PerfView ( .NET ).
- Инструменты Intel/AMD: VTune, AMD μProf — для глубокого анализа кешей и ветвлений.
- Для распределённых систем: tracing (OpenTelemetry, Jaeger) + профилирование в проде (sampled).
3) Инструменты для памяти
- Трассировка и дампы heap: massif (Valgrind), massif‑visualizer, heaptrack, jemalloc/jemalloc‑stats, tcmalloc/gperftools heap profiler.
- Для утечек: Valgrind memcheck, AddressSanitizer/LeakSanitizer, lldb/gdb heap inspection.
- Для JVM: heap dumps + MAT, VisualVM, Java Flight Recorder, YourKit.
- Для Go: pprof heap profiles, allocation/GC traces.
- Мониторинг в проде: прометей метрики (RSS, heap, GC pause), allocation rate.
4) Подходы и методики
- Sampling vs instrumentation: sampling профайлеры дают малый оверхед и реальную картину; инструментирование точнее, но искажает поведение и замедляет.
- Wall‑time vs CPU‑time: для I/O‑bound важен wall‑time; для CPU‑bound — CPU‑time.
- Flame graphs и call‑tree/flat отчёты — сначала смотреть где гуляет время (hot spots), затем смотреть кто вызывает эти функции.
- Репрезентативные нагрузки: профилировать на нагрузке, близкой к продовой, с правильным набором данных и прогревом (JIT).
- Стабильность измерений: несколько прогонов, брать медианы и перцентили, исключать «шум».
5) Как отличать оптимизацию алгоритма от преждевременной оптимизации
- Правило: сначала измерить. Оптимизация оправдана, если изменение затронет заметную долю времени/ресурсов (80/20 — сосредоточьтесь на «горячих» $\sim 20\%$, которые дают $\sim 80\%$ затрат).
- Оцените масштабируемость: если время растёт с размером входа как $O(n)$ vs $O(n^2)$, то алгоритм под вопросом.
- Используйте Amdahl для оценки возможного выигрыша: если доля времени, которую можно улучшить, равна $f$, а ускорение этой части — в $s$ раз, общий ускорение равно $\frac{1}{(1-f)+\frac{f}{s}}$.
- Правило полезности: оптимизируйте алгоритм/структуру данных, когда рост с входом или профиль ясно показывает доминирующий вклад. Мелкие оптимизации (микро‑оптимизации, инлайнинг, ручной unroll) — только после профиля и если алгоритм не бутылочное горло.
- Учитывайте стоимость: сложность кода, поддерживаемость, риск регрессий. Не стоит ухудшать читабельность ради микроскопического выигрыша.
6) Практический рабочий процесс (коротко)
- Определить метрики успеха.
- Собрать базовую статистику и профили (sampling) на репрезентативной нагрузке.
- Найти горячие точки (flame graph / flat profile).
- Решить: алгоритм/структура данных или оптимизация реализации/аллокатора/параллелизм.
- Внести изменения, написать микробенчмарки и E2E‑тесты, измерить до/после.
- Держать мониторинг в проде, чтобы ловить регрессии.
7) Полезные практические советы
- Не профилируйте debug‑сборки; прогрейте JIT.
- Сохраняйте профили (flamegraphs/pprof) для сравнения.
- Для многопоточных проблем используйте off‑CPU профилирование и инструменты для lock‑analysis.
- Если сомневаетесь, начните с low‑overhead sampling в проде, затем локально deep‑dive инструментами с большим оверхедом.
Если нужно, могу быстро предложить конкретный набор инструментов для вашего стека (язык/платформа), и шаблон профиля/метрик для запуска.