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

Ответ 1

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

Единственное время, когда большое количество операторов 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) {}.
Как только PHP увидит, что условие $a > 0 выполнено, весь оператор разрешен для истины (из-за использования значений OR) и не удосуживается проверить $b > 100 или $c > 200.

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

Ответ 2

Если - одни из самых дешевых операций - это по производительности.

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

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

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

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

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

Ответ 3

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

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

Ответ 4

Я только что наткнулся на очень интересный фрагмент статьи от 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.';
}

Хорошо: стиль шлюза

$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 спрашивает, являются ли важные условия истинными, и запускает только код, если они истинны.

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

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

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

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

Ответ 5

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

1) Если статус else должен быть в порядке убывания вероятности условий. В моей таблице таблицы wp_posts 80% записей имеют post_status "черновик", "ожидающий", "мусор" и т.д., Но не "публикуют". Около 40% записей имеют "сообщение" как 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() будет медленным. Если это какой-то запрос, который вы пишете сами и, конечно, зависит от того, насколько эффективен ваш запрос

Ответ 6

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