Практические правила преждевременной оптимизации

Ответ 1

Что такое преждевременная оптимизация?

Преждевременная оптимизация - это процесс оптимизации вашего кода (обычно для производительности), прежде чем вы узнаете, стоит ли это делать. Примером преждевременной оптимизации является оптимизация кода, прежде чем вы его профилируете, чтобы узнать, где узкое место производительности. Еще более экстремальный пример преждевременной оптимизации оптимизирует работу перед запуском вашей программы и установил, что она работает слишком медленно.

Разве мы находимся в точке, где решение между алгоритмом сложности O (n ^ n) и O (n!) не имеет значения? Что относительно O (n) vs O (n * n)?

Это зависит от размера n и того, как часто ваш код будет вызван.

Если n всегда меньше 5, то асимптотическая производительность не имеет значения. В этом случае размер констант будет иметь большее значение. Простой алгоритм O (n * n) мог бы выполнить более сложный алгоритм O (n log n) для малых n. Или измеримое различие может быть настолько маленьким, что это не имеет значения.

Я все еще думаю, что слишком много людей, которые тратят время на оптимизацию 90% кода, который не имеет значения, а не 10%. Никто не заботится, если какой-то код занимает 10 мс вместо 1 мс, если этот код почти никогда не называется. Бывают моменты, когда просто делать что-то простое, что работает и движется дальше, является хорошим выбором, хотя вы знаете, что алгоритмическая сложность не оптимальна.

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

Ответ 2

Мое голосование за то, что большинство людей оптимизируют то, что они считают слабым, но они не профилируются.

Итак, независимо от того, насколько хорошо вы знаете алгоритмы и независимо от того, насколько хорошо вы написали свой код, вы не знаете, что еще происходит за пределами вашего модуля. Что вы называете API-интерфейсом за кулисами? Можете ли вы всегда гарантировать, что конкретный порядок опций является самым быстрым?

Это то, что подразумевается под Premature Optimization. Все, что вы думаете, это оптимизация, которая не была тщательно протестирована с помощью профилировщика или другого окончательного инструмента (тактовые циклы с помощью ops - это не плохо, но это только говорит о характеристиках производительности. ~ Фактические вызовы важнее, чем время, обычно), является преждевременной оптимизацией.

@k_b говорит это намного выше меня, и это то, что я говорю тоже. Сделайте все правильно, сделайте это простым, затем профиль, затем настройте. При необходимости повторите.

Ответ 3

Порядок приоритета: 1. Он должен работать 2. Он должен быть поддерживаемым 3. Он должен быть машинным

Это было с первой недели моего первого курса программирования. В 1982.

"Преждевременная оптимизация" - это любое время. Приоритет 3 был рассмотрен до приоритета 1 или 2.

Обратите внимание, что современные методы программирования (абстракции и интерфейсы) предназначены для упрощения этой приоритизации.

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

Ответ 4

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

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

Большая часть кода iPhone связана с UI. Оптимизировать не нужно. Необходимо не выбирать плохой дизайн, который приведет к плохой производительности, но как только вы начнете кодировать хороший дизайн, мало нужно оптимизировать. Поэтому в этом контексте избежать оптимизации является разумной целью.

Ответ 5

Что вы считаете "преждевременным оптимизация"? Какие практические правила вы используете сознательно или бессознательно избегать этого?

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

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

Ответ 6

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

Иногда избегать преждевременной оптимизации может помочь дизайн, потому что, если вы разрабатываете идею, что вам нужно будет оптимизировать позже, то вы более склонны развиваться на абстрактном уровне (например, списке), а не в iimplementation (например, Array или связанный список).

Это может привести к более простому и понятному коду в дополнение к тому, чтобы избежать отвлечения внимания. Если запрограммировано на интерфейс, различные варианты реализации могут быть заменены позже, чтобы optmize. Преждевременная оптимизация приводит к риску, что детали реализации могут быть преждевременно выставлены и объединены с другими программными компонентами, которые не должны видеть эти детали.

Ответ 7

Какие практические правила вы используете для сознательно или бессознательно избегать этого?

Одним из способов избежать ненужной оптимизации является рассмотрение относительной экономической выгоды:

A) Стоимость программиста для оптимизации стоимости кода + для проверки указанной оптимизации + стоимость сохранения более сложного кода, полученного в результате указанной оптимизации

против.

B) Стоимость обновления сервера, на котором выполняется программное обеспечение, или просто купить другой (если масштабируемый)

Если A → B, подумайте, правильно ли это делать. [Игнорируя на данный момент стоимость окружающей среды B, которая может или не может быть связана с вашей организацией]

Это применимо в целом, а не только к преждевременной оптимизации, но это может помочь привить вашим разработчикам ощущение, что тратить свое время на работу по оптимизации - это затраты и не должны предприниматься, если нет реальной измеримой разницы в чем-то, что действительно имеет значение: количество требуемых серверов или удовлетворенность клиентов за счет улучшения времени отклика.

Если менеджмент не видит преимущества в сокращении $, и клиенты не могут видеть преимущества в лучшем времени отклика, спросите себя, почему вы это делаете.

Ответ 8

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

Я работал с решениями, где вызовы веб-сервисов были необходимы для вычисления новых значений на основе содержимого локального списка. То, как это было реализовано, - это сделать веб-запрос за значение. Не было бы преждевременной оптимизации отправлять несколько значений за раз. То же самое касается использования транзакций базы данных для нескольких операций, то есть нескольких вставок.

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