Делает ли короткое замыкание выполнение программы быстрее, и стоит ли анализировать, какой оператор поместить первым в оператор условия? [закрытый]

Например (допустим, мы говорим о C++, если это делает различие), В операторе && если я знаю, что один оператор будет приводить к 0 чаще/имеет более высокий шанс, чем другой оператор, должен ли я поместить его слева, а другой оператор справа?

То же самое относится и к оператору || если я знаю, что один оператор будет приводить к 1 чаще/имеет более высокий шанс, то другой оператор должен быть помещен в левую часть, а другой оператор-в левую часть. так ведь?

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

5 7
c++ performance logical-operators short-circuiting

5 ответов:

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

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

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

Например, если у вас есть что-то вроде: 

if(slowFunction() && complexConditionRootsAndExponents && ConditionUsuallyZero)
Тогда вы, вероятно, хотели бы, чтобы этот последний семестр был первым, не так ли? Однако будьте осторожны, вещи не всегда тривиальны для перестановки в логической последовательности. Проверьте например мой ответ в Почему эта программа напечатала вилку 4 раза?, где видно, что короткое замыкание может повлиять на ход выполнения программы.

TL; DR

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

4

Это зависит. Если утверждение так же просто, как: 

if(y == 4 || x == 2)

И предположим, что частота x == 2 намного выше, так что мы могли бы закоротить выполнение, написав: 

if(x == 2 || y == 4)

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

Теперь рассмотрим такой пример: 

if(y == an_expensive_function() || x == 2)

Здесь предположим, что an_expensive_function () является очень дорогостоящей операцией, скажем, что это сложность подобна экспоненциальной, то определенно имеет смысл поставить утверждение типа: 

if(x == 2 || y == an_expensive_function())

Для выполнения короткого замыкания.

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

5

Ответ на этот вопрос таков: Да, это влияет на производительность.

Стоит ли увеличение производительности затрат на поиск мест, которые можно улучшить, и изменение программы-это то, что только вы можете ответить.

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

Имейте в виду, что также могут быть последствия правильности. Например, если в if (foo() || bar()) это важно, что bar никогда не вызывается, если foo возвращает true, то это будет ошибкой, чтобы изменить порядок вызовов.

Начните с проверки правильности вашей программы . Затем, Если он слишком медленный; профильтруйте его и оптимизируйте, где он будет иметь наибольшее влияние. Это может быть порядком оценки в контексте короткого замыкания, но в большинстве случаев это будет что-то другое.
4

Вы также должны учитывать, насколько дорогостоящей является оценка каждой стороны.

if (veryCostlyOftenFalse() && veryCheapRareFalse()) // may be faster other way around

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

Программисты встроенных приложений / приложений реального времени фокусируются примерно в следующем порядке:

    Алгоритм, конечно, находя разумный компромисс в скорости против пространства.
  1. структуры данных в памяти (попадание в кэш как часто, насколько это возможно, при выполнении этих алгоритмов).
  2. профилирование реального приложения с реальными данными, чтобы увидеть, есть ли какие-то неожиданные узкие места и исправить их.
  3. если вы отчаянно не хватает где-то часы или два, и есть какой-то комплекс if вокруг, то да, это может помочь...
3

Конечно. если ваше условие имеет вид: 

if ( x() && y() ) ...

И y дорого вычислить, а x дешево и часто терпит неудачу, это позволит повысить локальную производительность кода.

Итак, вы хотите знать:

  • является условным в чувствительной к производительности части программы (если нет, нет смысла его оптимизировать, напишите для ясности)
    • Относительные затраты на компонентные вычисления выражения короткого замыкания
  • ]}
  • какие дешевые вычисления терпят неудачу (Для &&) или преуспевайте (для ||) часто.

В этом случае обычно стоит переставить элементы выражения короткого замыкания.

3