Техника оптимизации программного кода

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

А что сейчас? Вычислительные мощности современных компьютеров достигли фантастических (если сравнивать с тем, что было) значений, и даже такие «монстры», как Windows 7 не в силах их затормозить. И зачем нам оптимизировать, если так все нормально работает? Многие так и считают. Сейчас программирование дошло до такой стадии, что важнее стала скорость написания программ, чем скорость их работы. Потому что скорость их работы будет заведомо высокой. Но это относится лишь к обычным прикладным программам. Совсем другое дело драйвера (которые мало изменились еще со времен DOS), программы обработки аудио, видео, и графики, генерации паролей… В них про оптимизацию забывать ни в коем случае нельзя. Да и в обычных программах она никогда не бывает лишней. Куда приятней использовать более эффективную программу, чем идти в магазин за новым процессором. Или ждать, пока она соизволит загрузится, кому как лучше. Большинство пользователей выбирает первый вариант.

Оптимизация

В оптимизации есть несколько важных моментов:

Оптимизация должна быть естественной. Оптимизированный фрагмент кода должен легко вливаться в программу, не нарушая логики ее работы. Он должен легко вводится в программу, изменятся или удаляться из нее.
Оптимизация должна приносить существенный прирост производительности. Оптимизированная программа должна работать минимум на 20%-30% эффективней, чем ее неоптимизированный аналог, иначе она теряет смысл. Зачем мучится и вносить изменения в уже готовый код, если результата это практически не даст?
Разработка (и отладка) критических областей не должна увеличивать время разработки программы более чем на 10%-15%.
Как уже писалось ранее, сейчас на первый план выходит скорость разработки программ, так что все же не нужно отставать от остальной массы программистов. Себе же хуже.
Так же, перед тем как писать оптимизированный вариант, полезно иметь его неоптимизированный аналог. Обычно, оптимизированный код очень тяжел для восприятия, и если после его внедрения в программе появятся ошибки, то, подставив вместо него его менее эффективного собрата, мы можем определить, кто виноват в ошибках.

Логика оптимизации программного кода

Теперь перейдем к самой философии оптимизации. Считается, что критические области следует писать на ассемблере, поскольку он дает наивысшую скорость работы. Но зачастую результат работы оптимизирующего компилятора работает медленней своего ассемблерного аналога на 2%-7% (не более 20%). И стоило ли из-за такого мизерного прироста тратить время на разработку ассемблерной реализации? Из этого следует, что намного лучше оптимизировать код, написанный на языке высокого уровня, оптимизировать саму логику работы программы.

Основные постулаты оптимизации:

1. Начинать оптимизацию нужно с самых «узких» мест программы. Если мы будем оптимизировать те места, где и без нашего вмешательства все быстро работает, то прирост производительности будет минимален. Это основной закон оптимизации, от него мы и будем отталкиваться, разбирая остальные.
2. Оптимизировать лучше те места, которые регулярно повторяются в ходе работы. Этот закон относится к циклам и подпрограммам. Если можно хотя бы немного оптимизировать цикл, то делайте это не задумываясь. Если в одной итерации мы добьемся прироста в 2%, то после 1000 повторений это уже будет достаточно большое значение.
3. Старайтесь не слишком злоупотреблять оптимизацией единичных операций. Этот закон – своеобразное продолжение предыдущего. Оптимизируя фрагмент, который будет вызван лишь один раз, мы вряд ли добьемся ощутимого прироста (но если эффект будет ощутим (>10%, что бывает крайне редко), то оптимизация лишней не будет).
4. Используйте ассемблер только там, где скорость работы очень важна. Как уже писалось ранее, сейчас ассемблер не дает огромного прироста скорости. Поэтому использовать его стоит лишь в самых «узких» местах программы.
5. Задумывайтесь над оптимизацией. Неправильная оптимизация может даже навредить программе, увеличить время ее разработки, практически не уменьшив скорость ее работы.

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