CPU-профиль показывает, где тратится процессорное время
CPU-профилирование собирает выборки стека во время работы программы и показывает, какие функции чаще оказываются активными. Важно смотреть не только на функцию с большим собственным временем, но и на цепочку вызовов. Иногда медленный участок скрыт внутри библиотечной функции, которую вызывает ваш код. Flame graph и call graph помогают увидеть, откуда приходит нагрузка и насколько проблема локальна.
Heap-профиль помогает разобраться с памятью
Память можно анализировать по текущему объёму живых объектов или по общему числу выделений. Это разные вопросы. Большое число краткоживущих аллокаций создаёт нагрузку на сборщик мусора, даже если heap в конкретный момент невелик. Полезно проверять, какие типы и функции создают больше всего объектов, и только после этого решать, нужен ли reuse, изменение структуры данных или более аккуратная работа со строками и срезами.
Goroutine и блокировки раскрывают проблемы параллелизма
Высокая загрузка CPU не единственный источник медленной работы. Программа может ждать mutex, канал, сеть или внешний сервис. Профили блокировок и goroutine помогают увидеть, где конкуренция или ожидание становятся системными. Если тысячи goroutine стоят в одном и том же месте, проблема может быть в ограниченном ресурсе, а не в количестве потоков исполнения.
Benchmark связывает гипотезу с результатом
Микробенчмарк полезен после того, как найден конкретный участок. Он позволяет сравнить старую и новую реализацию в одинаковых условиях. Важно не забывать про реальную нагрузку: код, выигравший наносекунды в тесте, может ничего не изменить на уровне сервиса. Лучший результат — когда улучшение подтверждается и benchmark, и повторным профилем приложения.
Попробуйте на практике
Проведите учебное профилирование небольшого Go-кода.
- Напишите функцию, которая обрабатывает большой список строк.
- Запустите benchmark и зафиксируйте время и аллокации.
- Снимите CPU- и heap-профиль.
- Найдите одну функцию с заметной стоимостью и измените только её.
- Повторите benchmark и профиль после изменения.
Как проверить результат. Упражнение выполнено, если оптимизация выбрана по данным профиля и её эффект подтверждён повторным измерением.
Частые вопросы
Нужно ли профилировать до появления проблемы?
Полезно иметь базовые метрики, но глубокая оптимизация оправдана, когда есть измеримая цель или узкое место.
Высокое потребление памяти всегда означает утечку?
Нет. Нужно смотреть, удерживаются ли объекты дольше необходимого и растёт ли использование устойчиво.
Benchmark заменяет профилирование?
Нет. Benchmark хорошо сравнивает конкретные реализации, а профиль показывает, где вообще стоит искать проблему.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.