Имеет ли много аргументов if ухудшение скорости рендеринга php?

Неа. Фактически, это фактически ускорит его в большинстве случаев (потому что ему разрешено пропускать блоки кода).

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

 while (true) { if (count($some_array) == 0) { break; } /* some other code */ } 

Когда-либо итерация через цикл проверяет, есть ли count($some_array) == 0 . Это означает, что каждый проход PHP должен идти и вручную count количество элементов в $some_array потому что он может быть изменен. Это также относится к условию остановки в цикле for. Это связано с тем, что цикл for всегда можно переписать в виде цикла while:

 for ([INITIALIZER_ACTION]; [CONDITION]; [POST_ITERATION_ACTION]) { [CODE]; } 

такой же как…

 [INITIALIZER_ACTION]; while ([CONDITION]) { [CODE]; [POST_ITERATION_ACTION]; } 

Если вы планируете слить кучу утверждений if в одно: не делайте, вы не получите никаких преимуществ. PHP делает короткое замыкание, что означает, что если он достигнет точки, где он знает, каков будет результат, он пропустит остальное.

Например, рассмотрим $a = 5; if ($a > 0 || $b > 100 || $c > 200) {} $a = 5; if ($a > 0 || $b > 100 || $c > 200) {} .
Как только PHP увидит, что условие $a > 0 выполнено, весь оператор решил true (из-за использования значений OR) и не потрудился проверить $b > 100 или $c > 200 .

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

If-clauses – одни из самых дешевых операций, которые имеют производительность.

Однако то , что вы положили в if-предложение, может быть очень медленным.

Например, if (true) { ... } будет необычайно быстрым, но единственный if (calculatePi()) { ... } будет восприниматься буквально навсегда. Сам if себе так быстро, что вам никогда не придется беспокоиться об этом, и, кроме того, в значительной степени все остальное, что вы делаете, включает в себя несколько, if s в любом случае, например, когда вы делаете или в while циклы или инструкции switch . Все из них по существу содержат, if (один или несколько) внутри них.

Что касается дизайна, многие из них могут смущать других разработчиков, в зависимости от того, что вы пишете и как это написано. Иногда вам лучше использовать операторы switch / case или какой-либо другой рабочий процесс приложения, но, честно говоря, куча if вероятно, будет работать быстрее, чем любая структура, которую вы можете придумать. Но принимайте это близко к сердцу, если ваша единственная забота – это производительность. Я не повторяю, что разработка программного обеспечения не в первую очередь касается производительности. Хороший дизайн программного обеспечения касается других вещей, таких как ремонтопригодность, то есть, как легко читать и успешно обновлять свой код.

Короче говоря, если вы оптимизируете производительность, не беспокойтесь, пытаясь уменьшить количество if . Скорее сосредоточьтесь на том, о чем спрашивают if , или что происходит в зависимости от того, вернутся ли они true или false.

Надеюсь, поможет.

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

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

Я только что наткнулся на очень интересную статью из WPShout, которая использует очень человеческую аналогию, чтобы предложить нам более интеллектуально программировать и почему глубоко вложенные, if { .. } утверждения могут ухудшить не только производительность, но и удобство обслуживания кода. Если логика соответствует производительности, без лишних раздутых проверок итераций, скорее всего, вы получите довольно хорошо организованный, отзывчивый-чистый код.

ПРИМЕР КОДА (извлечен из статьи)

«Давайте сделаем это конкретным, посмотрев два простых примера кода: сначала в стиле пузыря, затем в стиле шлюза».

Плохо: Bubble-Style

 $is_first_thing_working = true; $is_second_thing_working = true; $is_third_thing_working = true; $is_fourth_thing_working = true; if( $is_first_thing_working === true ) { if( $is_second_thing_working === true ) { if( $is_third_thing_working === true ) { if( $is_fourth_thing_working === true ) { return 'Working properly!'; } else { return 'Fourth thing broken.'; } } else { return 'Third thing broken.'; } } else { return 'Second thing broken.'; } } else { return 'First thing broken.'; } 

Хорошо: Gateway-Style

 $is_first_thing_working = true; $is_second_thing_working = true; $is_third_thing_working = true; $is_fourth_thing_working = true; if( $is_first_thing_working !== true ) { return 'First thing broken.'; } if( $is_second_thing_working !== true ) { return 'Second thing broken.'; } if( $is_third_thing_working !== true ) { return 'Third thing broken.'; } if( $is_fourth_thing_working !== true ) { return 'Fourth thing broken.'; } return 'Working properly!'; 

ПРИМЕЧАНИЯ НА ПРИМЕРЕ

Разница между двумя фрагментами кода выше сводится к ключевому различию:

Метод bubble спрашивает, являются ли важные условия истинными, и запускает только код, если они истинны.

Метод шлюза спрашивает, являются ли важные условия ложными и немедленно выдает инструкции выхода для каждого условия, если оно ложно.

Метод пузыря заставляет вложенность, потому что перед тем, как перейти к коду, который вы хотите запустить, вам нужно проверить «true, true, true, true» . Каждый «истинный» чек – это уровень вложенности – условие, в котором ваш код должен жить внутри.

Метод шлюза не вложен: как вы видите, код не должен превышать один уровень логики. Это связано с тем, что, как только данный шлюз пройден, мы можем полностью его забыть. Другими словами, поскольку мы не выходим после нашей проверки $is_first_thing_working , мы автоматически знаем, что $is_first_thing_working верен для остальной части кода.

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

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

1) Если другой статус должен быть в порядке убывания вероятности условий. В моей конкретной wp_posts базы данных wp_posts 80% записей имеют post_status «draft», «pending», «trash» и т. Д., Но не «publish». Около 40% записей имеют «post» как post_type . Таким образом, было бы бессмысленно иметь

 if ($post_type=="post"&&$post_status=="publish") { doA(); } elseif ($post_type!="post"&&post_status=="publish") { doB(): } elseif ($post_type=="post"&&post_status!="publish") { doC(); } else { doD(); } 

но он должен идти в обратном порядке

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

В некотором смысле .. ДА .
Я говорю об этом с учетом худшего сценария, в данном случае очень крупного модельного объекта с большим количеством условий. Здесь код должен пройти через все условные проверки, которые в конечном итоге замедляют работу кода.
Условные утверждения создают трудности для распараллеливания и векторизации, а длинная серия IF-THEN также может вызывать промахи кэша команд и другие эффекты. Но если это делает код более ясным, используйте его.