Скорость работы кэша памяти и стека

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


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


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


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


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


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


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


Я пришел к выводу, что рефакторинг позволяет мне писать программы быстрее. На некоторое время он
делает программы более медленными, но облегчает настройку программ на этапе оптимизации. В конечном
счете достигается большой выигрыш.