По мотивам <a href="
http://www.linux.org.ru/jump-message.jsp?msgid=2158109 ">Что каждый программист должен знать о памяти</a>
ЛОР традиционно разделился на два полярных мнения. Часть лоровцев остаивала
тезис --- программы должны быть быстрыми и компактными. Тот, кто пишет такие программы, остальные --- тупые быдлокодеры, недочеловеки и вообще непонятно что они тут делают, когда страна так остро нуждается в метане.
некоторые же придерживались прямо противоположных взглядов:
антитезис --- большинству прикладных программистов не следует заморачиваться излишней оптимизацией.
В соответствии с марксистко-ленинской философией в результате столкновения тезиса и антитезиса должен произойти диалектический переход к синтезу, однако к сожалению оппоненты не владеют могучим аппаратом диамата и потому они оказались не в силах перейти к завершающей стадии. Попробую сделать это вместо них.
Итак, основная ошибка обоих сторон заключаются в том, что они рассматривают программу и эвм как две отдельные сущности, а это не верно. Сторонники оптимизации смотрят на проблему со стороны железа, ингорируя проблемы написания и сопровождения оптимизированных программ, тогда как противники стремятся максимально облегчить написание программ и им безразличны проблемы железа, пытающегося выполнить этот код за мало-мальски приемлимое время. Более правильный подход заключается в том, чтобы рассматривать программу и эвм как единую аппаратно-програмную сущность. (При этом не важно, что железо и софт поставляют разные дистрибьютеры). Проблему оптимизации следуюет рассматривать не в техническом, а в экономическом аспекте. С одной стороны нужно минимизировать затраты на написание програмной части. И тут на сцену выходит вижуал бэйсик, жаба, до-диез и другие флагманы ИНДУСтрии. С другой стороны также требуется минимизировать аппаратную часть ибо коммунизма до сих пор так и не построили (хотя пора бы уже по моему) и железо стоит денег. Таким образом мы имеем следующие зависимости:
* чем программы лучше тем она дороже, т.к. её написание требует большего времени, лучших программистов и большего их количества;
* чем программа лучше, тем меньше требование к аппаратной части;
* чем эвм дороже, тем она быстрее.
Эти зависимости можно отобразить в виде графика, в котором по оси абсцисс будет качество программ (например от лучшего к худшему), а по оси ординат --- стоимость програмно-аппаратного комплекса. Тогда стоимость програмной составляющей представляется монотонной убывающей кривой (чем хуже, тем дешевле), а стоимость аппаратной части --- монотонной возрастающей кривой (чем программа хуже, тем эвм нужна лучше). Где-то эти две кривые пересекутся и именно там будет находиться минимум себестоимости.
Проиллистрируем эти соображения простым примером. В коментариях к статье противникам оптимизации указывали на чрежмерную прожорливасть мозиллы как на результат, к которому приводит небрежное программирование. Рассмотрим гипотетическую ситуацию, пусть разработкой браузера займутся высококласные специалисты. Однако спецов мало, на всех не хватает и чтобы заманить их в свой проект mozilla foundation придётся как-то их промотивировать. Скорее всего деньгами. И браузер станет платным. Допустим оные профи смогут добиться снижения ресурсопотребления до уровня lynx при сохранения функционала мозиллы. Но браузер станет стоить штукубаксов. Пользователи встанут перед выбором: либо купить этот браузер, либо на эти же деньги купить новое железо, на котором и старый мозилла тормозить не будет. Думаю ясно что выберет конечный потребитель. Таким образом тормозное убожество оказывается лучше, чем действиельно качественная программа.
Вывод: программописательская отрасль не является вещью в себе, но подчиняется законам экономики точно так же как и все остальные отрасли промышленности. Текущее положение в it сфере обусловленно рядом социально-экономическим причин и оно принципиально несводимо к противостоянию пионер---быдлокодер. Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.