Когда мы приступаем к оптимизации системы (код, инфраструктура и т.п.), важно не торопиться и правильно наметить точки приложения усилий.

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

Эту идею хорошо иллюстрирует закон Амдала: итоговый выигрыш ограничен долей времени, которую занимал целевой участок.

Пример.
Общее время работы 100 мс, состоит из четырёх этапов:
A - 15 мс
Б - 5 мс
В - 10 мс
Д - 70 мс

Если ускорить Б в космические 10×, система в целом станет быстрее всего на 4.5%, тогда как оптимизация Д в 2 раза даст уже около 54% выигрыша.

И это при том, что затраченные усилия могли быть сопоставимы.

Поэтому начинать стоит с поиска того, что реально ограничивает систему. Иначе легко поддаться соблазну оптимизировать то, что просто лучше знаешь и в итоге потратить время впустую.

——

На эту тему было интересное обсуждение на LinkedIn, где подметили, что бутылочное горлышко системы не статично и со временем может менять форму и местоположение.

Поэтому цикл поиск узкого места → оптимизация → поиск узкого места можно повторять бесконечно 🙂