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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

К сожалению, это одна из тех дискуссий, которая на самом деле не закрыта.

Answer 3

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

Answer 4

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

Моя теория такова: «Пишите простой рабочий код, а затем оптимизируйте его по мере необходимости».