Делает ли короткое замыкание выполнение программы более быстрым и анализирует, какой оператор ставить первым в оператор условия стоит?
Например (допустим, мы говорим о C ++, если это имеет значение),
В && оператор, если я знаю, что одно утверждение приведет к 0 чаще / имеет больше шансов, чем другое утверждение, я должен поместить это слева, а другое утверждение справа?
То же самое касается || оператор, если я знаю, что одно утверждение приведет к 1 чаще / имеет более высокий шанс, чем другое утверждение, я должен поместить это слева, а другое утверждение справа?
Выполнение всего этого потребовало бы много времени для анализа программы, но если это ускоряет выполнение программы, стоит ли это делать, и это то, что программисты встраиваемых систем / систем реального времени изучают для ускорения своего приложения если необходимо?
Решение
Во-первых, убедитесь, что вы не являетесь жертвой преждевременная оптимизация.
С учетом сказанного, убедитесь, что вы сделали все возможное, чтобы ускорить горлышко бутылки вашей программы.
Делать то, что вы сказали о коротком замыкании, может быть хорошей идеей в некоторых случаях, но это сильно зависит от всех ваших заявлений.
Например, если у вас есть что-то вроде:
if(slowFunction() && complexConditionRootsAndExponents && ConditionUsuallyZero)
тогда вы, вероятно, хотели бы, чтобы последний срок был первым, не так ли?
Однако, будьте осторожны, вещи не всегда тривиальны, чтобы переставить в логической последовательности. Проверьте, например, мой ответ в Почему эта программа печатает вилку 4 раза?, где можно увидеть, что короткое замыкание может повлиять на ход выполнения программы.
TL; DR
Тем не менее, в целом, редко можно добиться значительного ускорения путем изменения условий в условиях. Сфокусируйтесь на узком месте вашей программы и постарайтесь справиться с этим как можно сильнее!
Другие решения
Это зависит.
Если утверждение так просто, как:
if(y == 4 || x == 2)
и предположим, что частота x == 2 намного выше, так что мы могли бы замкнуть выполнение, написав так:
if(x == 2 || y == 4)
Но вы видите, что мы не получим много пользы от этого, так как утверждения очень просты, и оптимизация кода на этом уровне, возможно, не будет столь достойной.
Теперь рассмотрим пример:
if(y == an_expensive_function() || x == 2)
Предположим, что an_exорого_function () является очень дорогостоящей операцией, скажем, ее сложность подобна экспоненциальной, и определенно имеет смысл выразить это утверждение следующим образом:
if(x == 2 || y == an_expensive_function())
выполнить короткое замыкание.
Разработчики встраиваемых приложений и приложений или любой разработчик в первую очередь могут не подумать об оптимизации с такой мелкой гранулярностью, если это не дает им больших преимуществ. Они могут даже не учитывать это, если у них все хорошо.
Поэтому, как разработчику, мы должны проверить, сколько времени потребуется для анализа и оптимизации кода на таком уровне и какую пользу мы получаем от этого.
Ответ на вопрос: да, это влияет на производительность.
Стоит ли повышение производительности затрат на поиск мест, которые можно улучшить, и на изменение программы — это только вопрос, на который вы можете ответить.
В большинстве случаев изменение производительности будет небольшим, но если Некоторые из операций являются дорогостоящими, это может быть значительным.
Имейте в виду, что также могут быть последствия правильности. Например, если в if (foo() || bar()) это важно что bar никогда не вызывается, если foo возвращает true, тогда было бы ошибкой переупорядочивать вызовы.
Начните с того, что ваша программа правильный. Затем, если это слишком медленно; профиль и оптимизировать, где это будет иметь наибольшее влияние. Тот может будет порядок оценки в контексте короткого замыкания, но в большинстве случаев это будет что-то другое.
Вы также должны учитывать, насколько дорогостоящей является оценка каждой стороны.
if (veryCostlyOftenFalse() && veryCheapRareFalse()) // may be faster other way around
Если более 50% вашего источника не являются оценками выражений и ветвлениями, я бы сказал, что это оптимизация в крайнем случае, когда вас устраивает все остальное.
Программисты встроенных приложений / приложений реального времени фокусируются примерно в следующем порядке:
- алгоритм, конечно, найти разумный компромисс в скорости против пространства.
- структуры данных в памяти (попадание в кэш как можно чаще при использовании этих алгоритмов).
- профилирование реального приложения с реальными данными, чтобы увидеть, есть ли какие-то неожиданные узкие места и исправить их.
- если вы отчаянно упускаете где-то часы или два, и есть какой-то сложный
ifвокруг, тогда да, это может помочь …
Конечно. если ваше условие имеет вид:
if ( x() && y() ) ...
и у дорого вычислять, а х дешево и часто терпит неудачу,
это улучшит локальную производительность кода.
Итак, вы хотите знать:
- является условным в чувствительной к производительности части программы (если нет, нет смысла ее оптимизировать, напишите для ясности)
- относительные затраты на вычисления компонентов выражения короткого замыкания
- какие дешевые вычисления не удаются (для &&) или успешно (для ||) часто.
В этом случае обычно стоит переставить элементы выражения короткого замыкания.