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

Question

Кажется, я замечаю две школы мысли об оптимизации:

1. Преждевременная оптимизация - корень всего зла . Вы должны оптимизировать только тогда, когда вы написали самую читаемую и простую вещь из возможных. Если после профилирования вы обнаружите, что программное обеспечение работает слишком медленно, вам следует выполнить оптимизацию.
2. Оптимизация должна быть сделана в начале жизненного цикла проекта . Оптимизацию нужно планировать, но нужно делать разумно.

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

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

Answer 1

Оптимизация на уровне дизайна и архитектуры на ранней стадии. Микро-оптимизация на уровне реализации позже.

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

Answer 2

Что я обычно делаю, так это применяю те оптимизации, которые мне ничего не стоят (или почти ничего). Я также остаюсь в поисках алгоритмов, которые плохо масштабируются и вызываются очень часто. Кроме этого, я не оптимизирую, пока не запустится программное обеспечение, и у меня не появится возможность запустить профилировщик. Только тогда я уделю серьезное время оптимизации.

Answer 3

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

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

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

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

Answer 4

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

Answer 5

Адаптируя цитату «это тактика, если вы выигрываете, и обманывает, если вы проигрываете», я бы сказал,

Это «планирование эффективности», если оно сработало, и «преждевременная оптимизация», если не сработало.

Answer 6

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

Answer 7

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

1. Знайте, как работают все стандартные контейнеры, в чем они хороши и в чем они плохи. например. SortedDictionary быстр при вставке и поиске, но плох при удалении. LinkedList быстро добавляется и удаляется, но плохо справляется с поиском и т. Д.
2. Знай, где будут твои горлышки от бутылок. Будь то процессор, диск, память, графика, ввод-вывод, работа в сети и т. Д. Знать, как эффективно использовать каждый из них, для каждой области требуются разные шаблоны проектирования. Это действительно зависит также от разрабатываемого приложения - на какой основной метрике следует сосредоточиться, чтобы обеспечить отзывчивость пользовательского интерфейса и хорошую обработку данных на диске.
3. Multhreading. Если приложение масштабируется до нескольких ядер, необходимо определиться с самого начала жизненного цикла разработки, если такая система необходима. Навинчивание болтов на более поздних этапах обходится гораздо дороже.

Некоторые ответы вы узнаете из опыта, некоторые потребуют исследования, но это никогда не будет догадкой.

Answer 8

Мне нравится формулировка этого парня .

1. Оптимизация с помощью более разумный общий подход.
2. Оптимизация за счет уменьшения кода странно.
3. Оптимизация путем создания код более странный.

Первые два - это ваш пункт 2. Его 3 - это ваш 1 и тот, который является корнем всего зла. И он прав: оптимизация, делающая код «более странным», делает его более сложным и трудным для понимания, что приводит к появлению новых ошибок и проблем с обслуживанием.

Answer 9

Код, помимо обеспечения основной функциональности, имеет еще три функции что разработчик программного обеспечения должен предоставить:

1. Производительность
2. ремонтопригодность
3. Надёжность

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

Answer 10

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

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