Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза. Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет

Здравствуйте, Аноним, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

Наверное в том, что корректно работающую программу проще переделать в быструю, чем быструю в корректно работающую.

А>И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза. Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет
Во первых зло это преждевременная низкоуровневая оптимизация — ручная раскрутка циклов, асмовые вставки, кэширования всяческих результатов везде подряд, кастомные менеджеры памяти, шаманская рассовывание данных и хитрых примитивов синхронизации etc.
Есть еще оптимизация высокоуровневая — архитектурная и алгоритмическая.
Так вот низкоеровневая оптимизация очень затрудняет алгоритмическую, которая в свою очередь часто затрудняет архитектурную. В то время как в большинстве случаев выигрышь в производительности распределяется в обратном порядке.
Потому вначале следует написать и заимплементить эффеективную архитектуру. Потом на этапе альфы пройтись профайлером и оптимизировать алгоритмы (поменять сортировки пузырьком на qsort, поиски на мапы, распараллелить долгие вычисления на несколько ядер etc.
И только потом, если маркетинг еще попросит чтоб было быстрее браться за профайлер еше раз, и заменять где требуется стандартные мапы на самописные, написать свой lookaside аллокатор для кучи объектов если профайлер показал >5% потерь на дефолтовом аллокаторе etc.

> Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

Потому что можно угрохать просто так кучу сил и времени. Например, оптимизированный (преждевременно) кусок кода, после прототипирования будет решено выкинуть. Или окажется, что тормоза в этом куске кода — пустяки по сравнению с тормозами в другом куске и оптимизировать надо было не здесь.

> И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза.

Пессимизация (т.е., написание кода без оглядки на его производительность) — еще большее зло.

> Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет

Вот именно на оптимизацию — да, пока забить. А вот заранее оценить потенциал быстродействия не помешает.

Здравствуйте, bexab, Вы писали:

B>Наверное в том, что корректно работающую программу проще переделать в быструю, чем быструю в корректно работающую.
Согласен. Оптимизировать/рефакторить программу многократно проще, когда она полностью работает и ее код покрыт тестами.

Здравствуйте, Аноним, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

Такой, что оптимизировать на уровне алгоритмов и структур данных нужно сразу.

А заменять boost::lexical_cast на велосипед не нужно, потому что это всегда можно сделать потом — и только в том месте, где по-настоящему тормозит.

А>И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза. Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет

Вот тебе реальная ситуация:
началось этим — http://rsdn.ru/forum/message/2229305.1.aspx

Автор: Ubivetz
Дата: 23.11.06

,
закончилось этим — http://rsdn.ru/forum/message/2231390.1.aspx

Автор: Ubivetz
Дата: 24.11.06

.

Здравствуйте, Аноним, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

В приведённой Вами — не знаю какой. Оригинал же выглядит так:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

И, на мой взгляд, это практически полный ответ на Ваш вопрос...
*Читайте первоисточники — они рулез

Здравствуйте, Аноним, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

А>И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза. Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет

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

Здравствуйте, Аноним, Вы писали:

А>...(поменять сортировки пузырьком на qsort...

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Аноним, Вы писали:

А>>...(поменять сортировки пузырьком на qsort...

E>IMHO от сортировки пузырьком следует отказаться раз и навсегда...
E>Вообще, можно завсети правило, что использование квадратичных и более медленных алгоритмов требует обоснования...
При работе с графами и кубы встречаются

Здравствуйте, skeptik_, Вы писали:

E>>IMHO от сортировки пузырьком следует отказаться раз и навсегда...
E>>Вообще, можно завсети правило, что использование квадратичных и более медленных алгоритмов требует обоснования...
_>При работе с графами и кубы встречаются

Здравствуйте, Erop, Вы писали:

А>>...(поменять сортировки пузырьком на qsort...
E>IMHO от сортировки пузырьком следует отказаться раз и навсегда...
E>Вообще, можно завсети правило, что использование квадратичных и более медленных алгоритмов требует обоснования...

Не раз видел, когда при необходимости всего-то найти пересечение двух множеств (заданных массивом\IList\IEnumerable, не важно) делался foreach по одному списку, а внутри него — по другому И на все пожелания сделать правильно отвечалось, что "нечего преждевременной оптимизацией заниматься", тогда как дело попросту в незнании более эффективных алгоритмов (что, к счастью, поправимо) и нежелании их узнать (с чем уже ничего не поделать)

Здравствуйте, _FRED_, Вы писали:

_FR>Не раз видел, когда при необходимости всего-то найти пересечение двух множеств (заданных массивом\IList\IEnumerable, не важно) делался foreach по одному списку, а внутри него — по другому И на все пожелания сделать правильно отвечалось, что "нечего преждевременной оптимизацией заниматься", тогда как дело попросту в незнании более эффективных алгоритмов (что, к счастью, поправимо) и нежелании их узнать (с чем уже ничего не поделать)

Ну, например, если завести какую-нибудь бюрократическую процедуру обоснования использования квадратичных и более медленных алгоритмов (например требовать писать докладную аписку начальнику с обоснованием), то программистам будет проще использовать правильные алгоритмы, и код улучшится практически забесплатно...

Аноним 791 wrote:

> Ведь оптимизация может привести к переписыванию много чего и даже в
> рамках одного модуля или класса. Какой смысл в этой фразе?

Очень хорошая тема, интересная. Только вот почему я её читаю в С++ ?
Очень странно.

Erop wrote:

> Ну, например, если завести какую-нибудь бюрократическую процедуру
> обоснования использования квадратичных и более медленных алгоритмов
> (например требовать писать докладную аписку начальнику с обоснованием),
> то программистам будет проще использовать правильные алгоритмы, и код
> улучшится практически забесплатно...

Для начала нужно написать другую бюрократическую процедуру — опознания
сложности алгоритма программистом.

Здравствуйте, MasterZiv, Вы писали:

MZ>Для начала нужно написать другую бюрократическую процедуру — опознания
MZ>сложности алгоритма программистом.


Эта процедура давно изрбретена

1) Пункт про согласование вносим в долж. инструкцию.
2) За нарушение должностной инструкции -- штрафуем.

Здравствуйте, Аноним, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?

А>И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза. Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет

если тормоза уже заметны, то, очевидно, это уже не преждевременная оптимизация

You will always get what you always got
  If you always do  what you always did

Здравствуйте, <Аноним>, Вы писали:

А>И реальная ситуация — есть какой-то проект который должен делать что-то. Сейчас сделана четверть нужной функциональности, но уже заметгны тормоза.
А> Судя по этой фразе — на оптимизацию пока надо забить, но ведь тогда может оказаться, что в конце будет такая ж..а, что на это никто сомтреть не станет
Судя по этой фразе забивать нужно на преждевременную оптимизацию. Если у вас уже сейчас видны тормоза, то это повод задуматься над их устранением. Если, конечно, есть уверенность, что эти тормоза — реальные, а не вызваны тем, что еще три четверти кода просто не написаны, а вместо них работают тормозные заглушки.
Преждевременная оптимизация — это, например, замена всех пузырьков на qsort без оглядки на реальные показания профайлера.
Вон уже народ понабежал с запретами на квадратичные алгоритмы. Бред ведь полнейший. Известна байка про то, как чувак переписал пузырек на квиксорт и получил 1% ускорения. А надо было перейти от строковых сравнений к сравнению perfect hash-ей, что дало рост перформанса в разы. Что характерно, такая замена дала бы почти такой же рост и для пузырька. Вот почему преждевременная оптимизация плоха.

Здравствуйте, Sinclair, Вы писали:

S>Преждевременная оптимизация — это, например, замена всех пузырьков на qsort без оглядки на реальные показания профайлера.
S>Вон уже народ понабежал с запретами на квадратичные алгоритмы. Бред ведь полнейший. Известна байка про то, как чувак переписал пузырек на квиксорт и получил 1% ускорения. А надо было перейти от строковых сравнений к сравнению perfect hash-ей, что дало рост перформанса в разы. Что характерно, такая замена дала бы почти такой же рост и для пузырька. Вот почему преждевременная оптимизация плоха.

Сортировку логично использовать стандартную , и уж точно в коде не должна появляться пузырьковая по определению.

Здравствуйте, Sinclair, Вы писали:

S>Вон уже народ понабежал с запретами на квадратичные алгоритмы. Бред ведь полнейший. Известна байка про то, как чувак переписал пузырек на квиксорт и получил 1% ускорения. А надо было перейти от строковых сравнений к сравнению perfect hash-ей, что дало рост перформанса в разы. Что характерно, такая замена дала бы почти такой же рост и для пузырька. Вот почему преждевременная оптимизация плоха.

Байка-то может быть и известна, кому-то. А вот зачем использовать сортировку пузырьком я не понимаю.
Может быть ты пояснишь зачем это надо?

---

1) За слово "бред", IMHO, можно и извиниться
2) Лично я предлагал не запрет на квадратичные алгоритмы, а требования обоснования их использования...