Оптимизация CPU-bound Go hot paths

Инженер Google поделился опытом оптимизации горячих путей в Go — без магии, с бенчмарками и парой неожиданных открытий.

Оптимизация CPU-bound кода — это как попытка выиграть гонку на Формуле-1, когда у тебя всего лишь велосипед. Но если велосипед написан на Go, шансы есть. В недавней заметке инженер из Google (а кто же ещё?) разобрал реальные кейсы ускорения hot paths — тех самых участков кода, где проседает производительность.

Что внутри?

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

Пара лайфхаков, которые мы подсмотрели:

Используйте sync.Pool для объектов, которые создаются часто и живут недолго — это как многоразовая посуда на пикнике, только для горутин.
Иногда стоит заменить map на слайс с бинарным поиском, если ключей не миллион, а доступ только на чтение. Да, это не так красиво, но быстрее.
И главное — не оптимизируйте вслепую. Профилируйте, профилируйте и ещё раз профилируйте. Иначе рискуете потратить неделю на ускорение того, что и так летало.

Комментарий студии METABYTE: У нас в METABYTE тоже есть свои hot paths — например, код, который обрабатывает заказы клиентов. Если бы мы не следили за производительностью, пришлось бы объяснять клиенту, почему его сайт тормозит. А мы предпочитаем объяснять, почему он летает. Так что профилирование — наше всё, только без фанатизма.