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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

Мне нравится этот парень.

• Оптимизация с использованием более разумный общий подход.
• Оптимизация путем сокращения кода странно.
• Оптимизация путем создания код более странный.

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

Моя теория гласит: "Напишите простой рабочий код, а затем оптимизируйте его по мере необходимости".

Ответ 10

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

Ответ 11

Существует одна основная истина:

Вы не можете оптимизировать то, что вы не можете проверить

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

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

К сожалению, это один из тех дебатов, которые не имеют реального закрытия.

Ответ 12

Базы данных, в частности, нелегки для рефакторинга и часто являются самым большим узким местом в системе из-за дизайнеров, которые думают, что им не нужно заботиться о производительности при их разработке. Это недальновидно. Существует много известных оптимизаций баз данных, которые почти все время будут быстрее. Не использовать их в своем дизайне и интуитивном кодировании, чтобы избежать "преждевременной оптимизации", является глупым. Например, курсор почти никогда (если вы не ищете текущие итоги) лучше работает, чем запрос на основе набора в SQl Server. Записывать курсор вместо запрограммированного набора не быстрее (как только вы понимаете запросы на основе набора), поэтому нет оснований начинать с кода на основе курсора. То же самое происходит с производными таблицами. Зачем писать код, который, как вы знаете, 90% времени будет медленнее, чем другой код, который занимает столько же времени, чтобы писать?

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

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

Ответ 13

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

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

Ответ 14

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

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

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