Говнокод - залог производительности

Существуют общепринятые правила хорошего тона при оформлении программного кода. Все их сформулировать довольно сложно, но давайте кратко остановимся хотя бы на следующих 3-х:
1. Осмысленные имена переменных.
2. Комментарии.
3. Избавление от повторяющегося кода.
По одной из классификаций языки программирования можно разделить на 2 группы: компилируемые языки и интерпритируемые. Ну про компилируемые тут особо ничего и не скажешь: какой машинный код на выходе компилятора получили — такой и будет работать. А вот с интерпритируемыми языками все гораздо интересней. Я говорю о том, что все эти правила хорошего тона влияют на производительность интерпретируемых языков программирования и снижают ее.

Эксперименты будем ставить над ПэХэПэ — отличный пример интерпретируемого языка, распространенней некуда, к тому же никаких тебе байткодов.
Итак, начнем с конца — избавления от повторяющегося кода. Сразу вспоминаем про include, ну заодно и проверим его. Идея такова: введем переменную сумма, изначально равную 0, и в 6 циклах по 10 итераций будем увеличивать ее на 1. Смысла в этом нет никакого, зато получится очень наглядно. Создадим 6 следующих пхп-файлов, незабывая про умные названия переменных (надеюсь я не переборщил с этим):

Пусть это будет файл 1.пхп

<code><?php 
    $Thisimportantvariableisthesum=0;
    for($Thisimportantvariableisthecount1=1;$Thisimportantvariableisthecount1<=10;$Thisimportantvariableisthecount1++)
    {
        include "2.php";
    }
    echo $Thisimportantvariableisthesum;
?></code>

Это у нас файл 2.пхп и файлы 3-5 по анологии с ним

<code><?php 
    for($Thisimportantvariableisthecount2=1;$Thisimportantvariableisthecount2<=10;$Thisimportantvariableisthecount2++)
    {
        include "3.php";
    }
?></code>

И файл 6.пхп

<code><?php 
    for($Thisimportantvariableisthecount6=1;$Thisimportantvariableisthecount6<=10;$Thisimportantvariableisthecount6++)
    {
        $Thisimportantvariableisthesum=$Thisimportantvariableisthesum+1;
    }
?></code>

В итоге получаем 100 000 инклудов — неплохо, заодно создадим по аналогии серии файлов с 10 000, 1000, 100, 10 инклудами и еще один вообще без них, с той же последовательностью действий, и замерим время исполнения каждого случая.
Про измерение: для измерения скорости выполнения использовался скрипт на питоне, делающий серию измерений для каждого примера, находящий среднее время и среднее отклонение от него в процентах.
А вот и результаты (скорость выполнения скрипта в секундах в зависимости от количества инклудов):

<code>
0       - 0.079(с.) ±0.58%
10      - 0.083(с.) ±2.02%
100     - 0.087(с.) ±1.20%
1000    - 0.135(с.) ±1.82%
10 000  - 0.554(с.) ±1.10%
100 000 - 4.346(с.) ±0.16%</code>

Со 100 000 все-таки я наверное перебрал, скорее всего сказалась динамическая типизация, но тем не менее прогресс на лицо, точнее на часах. Да, 100 000 инклудов в реальном проекте быть не может, а вот 10 инклудов или даже 100, если проект более или менее сложный, вполне себе имеют право на жизнь.
С инклудами разобрались, перейдем к кометариям. За основу опять возьмем пример с 100 000 инклудами и сдобрим каждый его файл несколькими киллобайтами комментариев. Кстати я наконец то нашел применение твиттеру, копипаст ленты американского президента отлично подошел для этого. В каждый файл, примерный размер которого изначально был около 100 Байт, было добавлено почти 7 КБ бесполезной информации. Много? Действительно много, но это сделано для наглядности. Итак, запускаем скрипт и пролучаем результат:
7.060(с.) ±1.93%
Да уж, разница заметна, время выполнения увеличилась примерно в полтора раза.
Перейдем к осмысленным именам переменных. Из предыдущего примера уже должно быть понятно, что сокращение названий переменных ускорит выполнение скрипта, но мы все же поэксперементируем, заодно уберем лишние отступы, пробелы и переносы. За основу опять взят вариант с 100 000 инклудами из первого теста, каждый из его файлов уменьшен в размере примерно в 2 раза за счет сокращения названий переменных и удаления лишних символов. Посмотрим на результат:
4.167(с.) ±0.17%
Разница есть, но хотелось бы больше. Вспомним, что мы сократили размер файлов всего на 50 Б, в отличии от 7 КБ, как в предыдущем примере, но повторимся еще раз: разница есть.

Вот собственно и все, доказательств того, что все эти правила хорошего тона при оформлении кода, в конечном итоге, заставляют его работать медленее, придостаточно. Хотите поспорить с этим? — попробуйте!
А вывод простой: писать быстрый как молния говнокод или красивые, но медленные как черепаха скрипты, в конечном счете, выбирать Вам.

---

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