Алгоритм любой оптимизации
Порядок шагов и сам факт их наличия важен. Можно представить ситуацию, где игнорирование какого-либо шага приведет к негативным последствиям
Также важно помнить, что в большинстве случаев производительность кода и его читаемость находятся в обратной зависимости, и задача сводится к поиску баланса между ними. Если бы абсолютный приоритет всегда отдавался производительности, мы бы писали программы на ассемблере. Но производительность не единственный критерий качества кода
Алгоритм:
1. Напишите хороший и понятный код, поддающийся легкому изменению
2. Задаться вопросом: А есть ли требование, чтобы было производительнее или это моя внутренняя потребность что-то оптимизировать?
3. Произвести измерение производительности ВСЕЙ системы до оптимизации
4. Найти бутылочное горлышко (Часть системы, которая вносит больший вклад в замедление производительности)
5. Произвести измерение производительности бутылочного горлышка
6. Написать тест на участок с бутылочным горлышком (если его еще нет)
7. Произвести оптимизацию (сохранив старую версию кода, чтобы можно было вернуться)
8. Произвести измерение производительности бутылочного горлышка и сравнить с измерением до оптимизации
9. Произвести измерение производительности ВСЕЙ системы и сравнить с измерением до оптимизации
Я считаю, что реальность такова, что проблемы начинаются на самом первом пункте. Почему-то сам процесс оптимизации довольно привлекателен для разработчиков. Возможно потому что скорость выполнения - довольно очевидная метрика. А может еще и потому, что обучение программированию в университетах происходит на языках вроде C++, где много внимания уделяется довольно низкоуровневым моментам вроде передачи по ссылке и т.д.. В итоге постоянно хочется всё оптимизировать. Но сам процесс оптимизации занимает время и при отсутствии требования к более высокой производительности, чем сейчас, это впустую потраченное время.
Когда я начинал программировать мне тоже очень нравилось заниматься оптимизациями. Тем более, что в инженерных расчетах результаты могли быть более заметными и например расчет вместо дней мог быть оптимизирован до секунд (если первая версия была совсем уж плохо написана). Но со временем к моему интересу оптимизировать добавился интерес писать понятный код, который удобно читать и использовать. Сейчас я считаю, что верно изначально писать именно читаемый и корректный код, а только потом проходится по описанному алгоритму оптимизации.
Есть много отличных мыслей на эту тему в книге Совершенный код (главы 25, 26).
И цитата Кнута про необходимость поиска бутылочного горлышка:
Программисты тратят огромное количество времени, размышляя или беспокоясь о скорости неключевых частей своих программ, и такие попытки повысить эффективность на самом деле оказывают сильное негативное влияние, если учитывать отладку и сопровождение. Мы должны забыть о незначительных оптимизациях примерно в 97% случаев: преждевременная оптимизация — корень всех зол.
Порядок шагов и сам факт их наличия важен. Можно представить ситуацию, где игнорирование какого-либо шага приведет к негативным последствиям
Также важно помнить, что в большинстве случаев производительность кода и его читаемость находятся в обратной зависимости, и задача сводится к поиску баланса между ними. Если бы абсолютный приоритет всегда отдавался производительности, мы бы писали программы на ассемблере. Но производительность не единственный критерий качества кода
Алгоритм:
1. Напишите хороший и понятный код, поддающийся легкому изменению
2. Задаться вопросом: А есть ли требование, чтобы было производительнее или это моя внутренняя потребность что-то оптимизировать?
3. Произвести измерение производительности ВСЕЙ системы до оптимизации
4. Найти бутылочное горлышко (Часть системы, которая вносит больший вклад в замедление производительности)
5. Произвести измерение производительности бутылочного горлышка
6. Написать тест на участок с бутылочным горлышком (если его еще нет)
7. Произвести оптимизацию (сохранив старую версию кода, чтобы можно было вернуться)
8. Произвести измерение производительности бутылочного горлышка и сравнить с измерением до оптимизации
9. Произвести измерение производительности ВСЕЙ системы и сравнить с измерением до оптимизации
Я считаю, что реальность такова, что проблемы начинаются на самом первом пункте. Почему-то сам процесс оптимизации довольно привлекателен для разработчиков. Возможно потому что скорость выполнения - довольно очевидная метрика. А может еще и потому, что обучение программированию в университетах происходит на языках вроде C++, где много внимания уделяется довольно низкоуровневым моментам вроде передачи по ссылке и т.д.. В итоге постоянно хочется всё оптимизировать. Но сам процесс оптимизации занимает время и при отсутствии требования к более высокой производительности, чем сейчас, это впустую потраченное время.
Когда я начинал программировать мне тоже очень нравилось заниматься оптимизациями. Тем более, что в инженерных расчетах результаты могли быть более заметными и например расчет вместо дней мог быть оптимизирован до секунд (если первая версия была совсем уж плохо написана). Но со временем к моему интересу оптимизировать добавился интерес писать понятный код, который удобно читать и использовать. Сейчас я считаю, что верно изначально писать именно читаемый и корректный код, а только потом проходится по описанному алгоритму оптимизации.
Есть много отличных мыслей на эту тему в книге Совершенный код (главы 25, 26).
И цитата Кнута про необходимость поиска бутылочного горлышка:
Программисты тратят огромное количество времени, размышляя или беспокоясь о скорости неключевых частей своих программ, и такие попытки повысить эффективность на самом деле оказывают сильное негативное влияние, если учитывать отладку и сопровождение. Мы должны забыть о незначительных оптимизациях примерно в 97% случаев: преждевременная оптимизация — корень всех зол.