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

Принцип Парето, известный также как «правило 80/20», гласит, что 80% результата можно получить, приложив 20% усилий. Относящийся не только к программированию, этот принцип очень точно характеризует оптимизацию программ.

Барри Бом сообщает, что на 20% методов программы приходятся 80% времени ее выполнения. Таким образом изменение нескольких строк кода может значительно увеличить скорость всего проекта.

Бабушкины сказки

Сокращение числа строк высокоуровневого кода повышает быстродействие или уменьшает объем итогового машинного кода — НЕВЕРНО!

Рассмотрим код инициализации массива из 10 элементов:
for i = 1 to 10
   a[ i ] = i
end for

Как вы думаете, он выполнится быстрее или медленнее, чем эти 10 строк, решающих ту же задачу?
a[ 1 ] = 1
a[ 2 ] = 2
a[ 3 ] = 3
a[ 4 ] = 4
a[ 5 ] = 5
a[ 6 ] = 6
a[ 7 ] = 7
a[ 8 ] = 8
a[ 9 ] = 9
a[ 10 ] = 10

Тесты показали, показали, что второй фрагмент минимум на 60% быстрее первого.

Одни операции, вероятно, выполняются быстрее или компактнее других — НЕВЕРНО! Если речь идет о производительности, не может быть никаких «вероятно». Без измерения производительности вы никак не сможете точно узнать, помогли ваши изменения программе или навредили.

Оптимизацию следует выполнять по мере написания кода — НЕВЕРНО! Кое-кто утверждает, что если вы будете стремиться написать самый быстрый и компактный код
при работе над каждым методом, то итоговая программа будет быстрой и компактной. Однако на самом деле это мешает увидеть за деревьями лес, и программисты, чрезмерно поглощенные микрооптимизацией, начинают упускать из виду по-настоящему важные глобальные виды оптимизации. Главный недостаток преждевременной оптимизации — отсутствие перспективы.

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

Подход к оптимизации кода

Рассматривая целесообразность оптимизации кода, придерживайтесь следующего алгоритма:
1. Напишите хороший и понятный код, поддающийся легкому изменению.
2. Если производительность вас не устраивает:
   a. сохраните работоспособную версию кода, чтобы позднее вы могли вернуться к «последнему нормальному состоянию»;
   b. оцените производительность системы с целью нахождения горячих точек;
   c. узнайте, обусловлено ли плохое быстродействие неадекватным проектом, неверными типами данных или неудачными алгоритмами и определите, уместна ли оптимизация  кода; если оптимизация кода неуместна, вернитесь к п. 1;
   d. оптимизируйте узкое место, определенное на этапе (c);
   e. оцените каждое улучшение по одному за раз;
   f. если оптимизация не привела к улучшению кода, вернитесь к коду, сохраненному на этапе (a) (как правило, более чем в половине случаев попытки оптимизации будут  приводить лишь к незначительному повышению производительности или к ее снижению).
3. Повторите процесс, начиная с п. 2.