Обратимся к первоисточникам

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

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

Обратимся к первоисточникам. Упомянутую цитату можно найти в статье: Knuth, D. E. 1974. Structured Programming with go to Statements. ACM Comput. Surv. 6, 4 (Dec. 1974), 261-301.

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

Я отстаиваю точку зрения, что оптимизация программы — это спланированные действия, которым уделяется достойное внимание в процессе разработки всей системы. Тестирование производительности должно осуществляется наравне с функциональным тестированием, относительно требований к производительности системы. Очевидно, что обнаруженная проблема производительности имеет более высокий приоритет, чем основные задачи по разработке, для широкого класса приложений: компьютерные игры, аудио/видео кодеки, системы управления критическими объектами. Исправление проблемы производительности — это и есть оптимизация, которая выполнена своевременно, задолго до окончания разработки программы. Своевременное исправление таких проблем ведет к снижению рисков проекта. И наоборот: оставленные проблемы на «потом» приводят лишь к срыву сроков проекта и к невыполнению требований по производительности.

Можно сформулировать следующие рекомендации:

• определить требования к производительности (например, сколько кадров в секунду должна показывать игра или сколько времени должна занимать обработка файла);
• разработать тесты производительности относительно поставленных требований (их можно сделать в рамках unit-тестирования);
• тестировать производительность наравне с функциональным тестированием;
• при обнаружении проблем сосредоточиться лишь на тех фрагментах кода, которые дадут максимальный выигрыш.

А вообще, судя по аннотации, статья посвящена тому, как избавиться от оператора go to. Разумеется, студенты специальности СКС могут свободно ознакомиться с этой статьей, связавшись со мной по электронной почте. :)