Если утверждения внутри или снаружи цикла?

Ответ 1

Я оставлю преждевременную оптимизацию.

"Преждевременная оптимизация - корень всего зла" - Дональд Кнут

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

Если вы позже определите, что производительность является проблемой, попробуйте измерить что-то вроде профилировщика, чтобы увидеть, где узкие места. Скорее всего, это не так. Из кода Complete 2:

Барри Бем сообщает, что 20% программные процедуры потребляют 80 процентов от времени его выполнения. В его классическая статья "Эмпирическое исследование Фортран", - заявил Дональд Кнут что менее четырех процентов программа обычно составляет больше, чем 50% времени выполнения.

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

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

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

EXTRA: Чтобы ответить на вопрос о самой производительности:

Этот [ "unswitching" код] хорош примерно на 20 процентов экономии времени:

Language        Straight Time    Code-Tuned Time    Time Savings
C++             2.81             2.27               19%     
Java            3.97             3.12               21%
Visual Basic    2.78             2.77               <1%
Python          8.14             5.87               28%

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

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

Проверьте этот другой вопрос здесь. И this из первого выпуска кода Complete.

Ответ 2

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

И поскольку переменная сравнения является инвариантом цикла, я был бы удивлен, если бы не было более четкого кодирования.

Фактическая разность скоростей (время настенных часов) зависит от размера массива

Ответ 3

Если вы оптимизируете скорость, вторая (foreach петли внутри ветвей if) должна быть быстрее, так как вы не будете проходить тест в каждой итерации цикла.

Ответ 4

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

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

 my $sub_ref = $bool ? make_true_function() : make_false_function();

 foreach my $element ( @array ) {
      $sub_ref->( $element );
      }

 sub make_true_function  { sub { ... } }
 sub make_false_function { sub { ... } }

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

Ответ 5

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

Ответ 6

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