Программист про (преждевременную) оптимизацию⁠⁠

Всем привет, работаю java разработчиком больше 10 лет. У написанного кода есть разные характеристики: производительность, читаемость, покрытие тестами, стоимость строки итд. Команды разработки могут управлять этими характеристиками в некоторых пределах. В этом посте хотел бы осветить вопрос оптимизации производительности.

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

List<String> visitorIds;
Set<String> visitorIds;
print(visitorIds.contains("123"));

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

Сложнее обстоит дело с индексами в БД - есть инструменты чтобы выбрать правильные индексы, но этот вопрос нужно решать на месте. Не добавил индекс - будет медленное чтение, добавил индекс - медленная запись и повышенное потребление диска. Потребовалось добавить индекс на большом размере данных - нужно останавливать сервис.

Еще сложнее обстоит вопрос с настройкой ресурсов - какой размер пула потоков установить? Кто съел все коннекты к бд, почему повышенное потребление памяти? На этом этапе приходится подключать средства профилирования. Для получения воспроизводимого результата нужно иметь процедуру нагрузочного тестирования. Как будем мерять производительность - по пропускному потоку или по задержке?

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

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

• перенести всю логику из java в sql (код админки, нагрузка ~100 запросов в день)

• ускорить расчет закрытия предыдущего дня (при том что расчет не нуждался в ускорении)

• использовать параллелизацию (что ломает компоненты, ориентированные на thread per request подход)

Общая рекомендация здесь такая - если вы не знаете, что делаете - лучше не делать ничего. Сделайте по-простому, и потом улучшайте там где вылезают самые острые проблемы. Желаю всем интересных задач и достойной оплаты!