Интуиция о медленности обычно неверна

Врач, который назначает операцию по догадке, ни разу не сделав анализ, — уверенный, быстрый и слишком часто оперирующий совсем не то.

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

Действовать по чутью — значит оптимизировать не то, добавить сложность и остаться с медленной программой. Первый ход — никогда не «почини», а узнай, куда на деле уходит время.

Карта: 20 понятий в семи группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Все понятия курса делятся на семь групп — по одной на главу. Сначала — как измерять. Потом — какой именно «быстро» тебе нужен. Потом — узкое место и классические починки. Потом — как не дать среднему себя обмануть, когда не надо оптимизировать, и как вести всю работу циклом.

Как читать курс

Механик не меняет детали наугад: сначала приборы, потом одна починка, потом проверка.

У каждого понятия одно и то же: английское название (запомни его — это термин из документации, профайлеров и дашбордов), образ из жизни, схема и карточка с полями что это, как работает, пример, подвох и связи.

Главная идея курса: производительность — это не набор трюков, а метод. Измерь → найди узкое место → почини одно → измерь снова → остановись на цели. Всё остальное в курсе — детали этого цикла.

Profiling — найди реальную стоимость

Детализированный счёт, где видно, куда ушли деньги, строка за строкой. Ты перестаёшь гадать и видишь, что бюджет съел один платёж — и не тот, на который ты думал.

Профайлер (profiler) — инструмент, который меряет, где программа на деле проводит время, функция за функцией. Он превращает «думаю, это медленно» в «эта одна функция — 80% времени выполнения». С этим ты чинишь то, что важно, а не то, что вообразил.

Профайлер ли это, логи с таймингами или метрики наблюдаемости (observability) — принцип один: пусть на проблему указывает измерение, а не интуиция.

Measure–Fix–Measure — измерь, почини, измерь снова

Учёный меняет одну переменную, перезапускает опыт и проверяет результат — никогда не предполагая, что изменение помогло, всегда подтверждая.

Производительность — это цикл: измерь, чтобы найти медленную часть, измени её, потом измерь снова, чтобы подтвердить, что изменение правда помогло, — а не просто сдвинуло проблему или сделало хуже.

Без второго измерения ты гадаешь, улучшил ли что-то. Именно так «оптимизации» тихо делают всё медленнее. Относись к каждой починке как к гипотезе, которую проверяешь, — та же дисциплина, что эвалы для ИИ или тесты для кода.

Latency — ожидание одной вещи

Сколько занимает один кофе от заказа до чашки — опыт одного клиента, от начала до конца.

Задержка (latency) — сколько занимает одна операция от начала до конца: один запрос, одна загрузка страницы, один запрос к базе. Это то, что отдельный пользователь чувствует: ожидание.

Когда кто-то говорит «сайт медленный», он почти всегда имеет в виду задержку — паузу между действием и ответом. Снижать задержку — значит делать каждую отдельную вещь быстрее.

Throughput — сколько обрабатываешь в секунду

Сколько кофе вся кофейня подаёт за час — не сколько занимает один, а общий поток через заведение.

Пропускная способность (throughput) — сколько работы система обрабатывает за единицу времени: запросов в секунду, задач в минуту. Это про общую ёмкость, а не про отдельное ожидание.

У системы может быть отличная пропускная способность (обслуживает тысячи разом), пока каждый пользователь всё равно ждёт (высокая задержка). Или низкая задержка, но ограниченная ёмкость. Это разные цели, и от того, какую ты гонишь, зависит, что ты чинишь.

Batching — пропускная способность ценой задержки

Мотоцикл довозит одного человека быстрее всех (низкая задержка); автобус перевозит больше всего людей за рейс (высокая пропускная способность). Лучший транспорт зависит от того, что тебе нужно.

Задержка и пропускная способность независимы, и оптимизация одной может навредить другой. Батчинг (batching) — группировка работы — часто поднимает пропускную способность, но добавляет задержку: каждый элемент ждёт, пока соберётся пачка.

Поэтому реши, что важно здесь. Страница для пользователя живёт или умирает на задержке; фоновый конвейер данных заботится о пропускной способности. Назови свою реальную цель — и не будешь оптимизировать число, которое не важно твоим пользователям.

Bottleneck — одна медленная часть доминирует

Цепь ровно настолько крепка, насколько её слабейшее звено. Усиливать крепкие звенья бесполезно — только слабое решает, выдержит ли она.

В большинстве медленных систем одно узкое место (bottleneck) отвечает за бо́льшую часть времени — один запрос, один медленный сервис, один плохой цикл. Всё остальное уже достаточно быстро.

Поэтому гадать так расточительно: весь навык — найти доминирующую стоимость, а не улучшать быстрые части.

Limiting Step — система быстра настолько, насколько её самый медленный шаг

Шоссе свободно, пока не одно перекрытие полосы, где все ползут. Скорость всей поездки задаёт это одно место, а не свободные участки.

Запрос, который проходит десять шагов, ограничен самым медленным из них — это ограничивающий шаг (limiting step). Ускорить девять быстрых шагов — итог почти не сдвинется; темп задаёт медленный. Так что ты целишься именно в него.

И заметь: починка одного узкого места часто открывает следующее. Убери самый медленный шаг — появится новый самый медленный. Работа над производительностью — это повторяющийся поиск и расчистка того, что ограничивает систему сейчас.

Amdahl's Law — оптимизация в другом месте впустую

Полировать кубок, пока у машины спущено колесо, — усилие там, где оно ничего не меняет, а то, что тебя на деле останавливает, лежит нетронутым.

Оптимизируешь часть, которая занимает 2% времени, — лучшее, что выиграешь, это 2%. Найди часть на 80% — и её починка меняет всё. Эту арифметику называют законом Амдала (Amdahl's law): выигрыш ограничен долей времени, которую занимает ускоряемая часть.

Время на оптимизацию чего угодно, кроме узкого места, по определению не может заметно помочь. Часто оно делает хуже — сложность и баги ради невидимого выигрыша. Измерение не даёт тебе любовно полировать часть, которую ты понимаешь, и заставляет взяться за ту, что правда стоит. Чини узкое место, остальное игнорируй — пока остальное само не станет узким местом.

Better Algorithm (Big-O) — лучший алгоритм бьёт более быструю машину

Два маршрута в один город: быстрая машина на длинной извилистой дороге всё равно проигрывает медленной на прямом срезе. Маршрут важнее двигателя.

Крупнейшие выигрыши часто дают лучший алгоритм или структура данных, а не железо и не микроправки. Как растёт время с ростом входа, описывает Big-O. Цикл O(n²), заменённый на поиск O(n) через хеш-таблицу, может превратить минуты в миллисекунды — никакая более быстрая машина так не сможет.

Прежде чем оптимизировать мелочь, спроси, не неверен ли сам подход. Лучшая форма, как показывает курс о структурах данных, — самое дешёвое и самое крупное ускорение из всех.

N+1 Query — слишком много круговых поездок

Двадцать отдельных походов в магазин за одной вещью каждый вместо одного похода со списком — твой день съедает дорога, а не покупки.

Огромная доля медленности — слишком много круговых поездок (round trips): повторные вызовы базы или сервиса, каждый дешёвый сам по себе, но разрушительный в массе.

Классика — запрос N+1 (N+1 query): достать список, а потом сделать ещё по запросу на каждый элемент. Один поход превращается в сотни. Лекарство — доставать оптом, спросить всё разом. Уменьшить число поездок обычно выгоднее, чем ускорять каждую, потому что сама поездка и есть стоимость.

Caching — не считай одно и то же дважды

Готовить блюдо с нуля каждый раз, когда кто-то просит, вместо того чтобы держать кастрюлю тёплой, — самая быстрая работа та, что не повторяешь.

Кэширование (caching) — запомнить дорогой результат, чтобы не пересчитывать его. Это один из крупнейших рычагов вообще (у него свой курс).

Первый запрос идёт по долгому пути и сохраняет результат; следующие получают его из памяти. Цена — память и риск отдать устаревшие данные.

Doing Less — самая быстрая работа та, что ты пропустил

Не готовить то, что никто не заказал, и не накрывать стол на двадцать, когда пришли трое.

Ещё одна классика — делать меньше (doing less). Вычисляй вещи лениво (lazy) — только когда они правда нужны. Не загружай данные, которые не используешь. Пропускай работу, результат которой всё равно выбросишь.

Самая быстрая операция — та, что ты никогда не запускаешь. Часто лучшая оптимизация не в том, чтобы делать работу быстрее, а в том, чтобы не делать её вовсе.

Average — среднее прячет медленные случаи

В комнате девять человек в комфорте и один в огне — средняя температура приятная. Среднее стирает тот случай, который на деле важен.

Сообщать производительность как среднее (average, mean) опасно успокаивает: оно смешивает быстрое большинство с медленным меньшинством в одно счастливое число. Но пользователи не живут в среднем — каждый живёт в своём запросе, и медленные чувствуют каждую миллисекунду.

Среднее время ответа 200 мс может прятать, что один пользователь из двадцати ждёт пять секунд. Среднее говорит «всё в порядке», пока реальная доля пользователей страдает.

Percentiles — p50 и p99 показывают реальный опыт

Отчёт, где написано не только типичное ожидание, но и «самый медленный 1% людей ждал вот столько», — плохие случаи названы, а не усреднены.

Перцентили (percentiles) показывают то, что прячет среднее. p50 (медиана) — типичный случай: половина запросов быстрее. p99 — медленный хвост: 99% быстрее, так что это примерно худший опыт, который встречает реальный пользователь.

Следить за p99, а не только за средним, — вот как ты видишь тех, кто правда страдает. Хвост — это место, где живёт боль, а перцентили делают её видимой.

Tail Latency — то, что пользователи помнят

Один ужасный ужин в ресторане перевешивает в памяти дюжину нормальных — худшие переживания, а не среднее, формируют то, как тебя судят.

Медленные запросы — хвост (tail latency) — непропорционально формируют то, как пользователи воспринимают продукт, потому что плохой опыт запоминается.

И в масштабе хвост задевает больше людей, чем кажется. Если страница делает много вызовов, шанс, что хотя бы один медленный, быстро растёт, — и почти каждый пользователь рано или поздно чувствует хвост. Поэтому серьёзные команды ставят цели на p99, а не на среднее: приручить худшие случаи — вот что делает продукт стабильно быстрым.

Premature Optimization — корень всех зол

Укреплять каждую стену дома против землетрясения, которого может и не быть, до того как кто-то вообще въехал, — огромное усилие на проблему, которой у тебя пока нет.

Знаменитая фраза Дональда Кнута — «преждевременная оптимизация (premature optimization) — корень всех зол» — предостерегает от оптимизации до того, как ты знаешь, что́ и нужно ли вообще ускорять.

Оптимизировать код, который не медленный или даже редко запускается, не даёт ничего и стоит немало: сложность, баги и время, украденное у того, что важно. Большинству кода не нужно быть быстрым — ему нужно быть верным и ясным. Работа над скоростью — для частей, которые измерение доказало горячими (hot).

Correct → Clear → Fast — сначала верно и ясно, быстро там, где важно

Ты пишешь рецепт так, чтобы любой мог по нему готовить, и упрощаешь только тот шаг, что делаешь сто раз в день, — не каждый шаг, только горячий.

Порядок такой: сделай верным (correct), сделай ясным (clear) и сделай быстрым (fast) только там, где измерение показывает, что это важно.

Ясный код легче оптимизировать потом — именно потому, что ты его понимаешь. Запутанный «быстрый» код трудно чинить, когда настоящее узкое место появляется в другом месте. Скорость почти всегда стоит читаемости, так что эту цену платишь только там, где она покупает реальный, измеренный выигрыш, а остальное держишь простым.

Performance by Design — но не игнорируй производительность в дизайне

Ты не делаешь сейсмоустойчивым сарай, но и не строишь небоскрёб на песке. Некоторые решения дёшево принять верно рано и разорительно чинить поздно.

Предупреждение — не «никогда не думай о производительности». Выбрать алгоритм O(n²) там, где O(n) был так же лёгок, или структуру, которая не масштабируется, — это ошибка дизайна, за которую дорого заплатишь потом.

Баланс такой: не микрооптимизируй рано, но и не делай архитектурных выборов, которые медленны по дизайну и дороги в откате. Большую форму выбери верно и дёшево заранее; детали оптимизируй, только когда измерение требует.

Optimization Loop — измерь, почини узкое место, повтори

Механик диагностирует приборами, чинит одну отказавшую деталь, потом проверяет снова — и никогда не меняет детали наугад в надежде, что стук пропадёт.

Метод простой и дисциплинированный: измерь, чтобы найти узкое место, почини его одно, измерь снова, чтобы подтвердить и увидеть следующее узкое место, и остановись, когда достаточно быстро.

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

Performance Target — поставь цель, потом остановись

Ты утепляешь дом, пока не станет достаточно тепло, и останавливаешься — а не добавляешь утеплитель вечно, за пределом того, что кто-то может почувствовать.

У производительности нет естественного конца — всегда можно сделать чуть быстрее. Так что поставь цель (performance target) — «страницы быстрее 300 мс на p99» — и остановись, когда достиг.

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

Как всё связано

Карта маршрута целиком: видно, откуда начинаешь, через какие станции идёшь и где выходишь.

Понятия курса складываются в одну картину. Профилирование находит узкое место; цель — latency или throughput — говорит, что именно чинить. Узкое место обычно лечится одной из четырёх классик: лучший алгоритм, меньше круговых поездок, кэш или меньше работы. Потом — измерить снова, по перцентилям, против цели, и остановиться. А преждевременная оптимизация — то, что случается, когда пропускаешь измерение.