Производительность и память

Производительность — свойство системы при заданной нагрузке и ограничениях, а не один показатель скорости. Этот раздел связывает стоимость алгоритма с устройством памяти, очередями, runtime и измерениями.

Зачем это на интервью

Интервьюер проверяет, умеет ли кандидат перейти от симптома — медленного запроса, роста p99 или нагрузки GC — к проверяемой гипотезе. Хороший ответ называет входные данные, метрики, компромисс и способ подтвердить изменение измерением.

Результат раздела

После раздела можно оценить порядок затрат, объяснить, почему два алгоритма с одинаковой Big O работают по-разному, и спланировать безопасное улучшение горячего пути.

Темы

1. Big O: время и память
2. Амортизированная сложность
3. CPU cache и локальность данных
4. False sharing
5. Скорость аллокаций и давление на GC
6. Throughput, latency и tail latency
7. Профилирование производительности

Ключевые понятия

• Асимптотическая, амортизированная и фактическая стоимость операции.
• Working set, cache line, locality, когерентность кэшей и false sharing.
• Allocation rate, live heap, GC pause, throughput, percentiles и saturation.
• Benchmark, профиль, trace, baseline и воспроизводимая нагрузка.

Минимум для E4

• Различать сложность по времени и по дополнительной памяти.
• Объяснять, почему Big O не заменяет измерение на реальной нагрузке.
• Читать p50/p95/p99 вместе с throughput, error rate и saturation.
• Профилировать до оптимизации и повторно измерять после неё.

Углубление для E5/Senior

Улучшение горячего пути оценивают как изменение целого ресурса: CPU, память, сетевые ожидания, конкуренция и стоимость эксплуатации. Старший инженер задаёт SLO, строит репрезентативный benchmark, ищет узкое место профилем и выкатывает изменение с наблюдением за хвостом распределения, а не с опорой на один микробенчмарк.

Типовые вопросы

1. Почему алгоритм $O(n)$ может быть медленнее $O(n\log n)$?
   • Константы, аллокации, locality, ветвления и рабочий набор могут доминировать на реальном диапазоне входов.
2. Что означает p99?
   • Это значение, ниже которого завершились примерно 99% измеренных запросов в выбранном окне; его интерпретируют с объёмом выборки и нагрузкой.
3. Когда нужно оптимизировать?
   • После постановки целевой метрики и подтверждения узкого места измерением; не по ощущению от кода.
4. Почему рост heap не равен утечке?
   • Heap может вырасти до рабочего уровня из-за нагрузки или политики runtime; утечку подтверждает удержание объектов и тренд после снятия нагрузки.
5. Какая метрика докажет ускорение?
   • Зависит от цели: например, p99 при фиксированном throughput и error rate, а также CPU и память как ограничения.

Практика

• Для каждого из семи материалов составьте одну проверяемую гипотезу производительности. Готово: указаны нагрузка, целевая метрика, baseline и критерий успеха.
• Запустите benchmark до и после одного изменения. Готово: сохранены команды, результаты не смешивают разные входы, а вывод содержит trade-off по CPU или памяти.

Частые ошибки и ловушки

• Считать более низкую Big O автоматической победой без диапазона входов и измерения.
• Оценивать только среднее время и игнорировать очередь, ошибки и хвост распределения.
• Смешивать нагрузочный тест, микробенчмарк и production-трафик как эквивалентные эксперименты.
• Вносить несколько оптимизаций сразу и терять причинность результата.

Связанные темы

База разработки и Computer Science · Планирование CPU · Go · Наблюдаемость

Источники

• Brendan Gregg, Systems Performance, главы о методе, CPU и задержках.
• Go project, документация Profiling Go Programs и Diagnostics.
• Ulrich Drepper, What Every Programmer Should Know About Memory.