Следует ли перемещать нетривиальные условные операторы в раздел инициализации циклов?

Я получил эту идею из этого вопроса на stackoverflow.com

Следующий шаблон является распространенным:

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

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

Это лучше объявить в разделе инициализации цикла, как таковой?

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

Это более понятно?

Что делать, если условное выражение простое, такое как

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

Я бы сделал что-то вроде этого:

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

Честно говоря, единственная веская причина, чтобы втиснуть инициализацию j(сейчас limit) в заголовок цикла, состоит в том, чтобы держать его правильно. Все, что нужно для того, чтобы не создавать проблем, - это хороший ограниченный объем.

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

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

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

Тем не мение...

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

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

Как сказал @Karl Bielefeldt в своем ответе, обычно это не проблема.

Однако когда-то это было распространенной проблемой в C и C ++, и уловка была в том, чтобы обойти эту проблему без снижения читабельности кода - повторять в обратном направлении, вплоть до0 .

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

Теперь условием каждой итерации является то, >= 0что каждый компилятор будет компилироваться в 1 или 2 инструкции по сборке. Каждый процессор, созданный за последние несколько десятилетий, должен иметь такие базовые проверки; делая быструю проверку на моей машине x64, я вижу, что это предсказуемо превращается вcmpl $0x0, -0x14(%rbp) (значение long-int-сравнения 0 против смещения регистра rbp -14) и jl 0x100000f59(переход к инструкции, следующей за циклом, если предыдущее сравнение было верным для «2nd-arg» <1-й аргумент ”) .

Обратите внимание, что я удалил + 1из Math.floor(Math.sqrt(x)) + 1; чтобы математика сработала, начальное значение должно бытьint i = «iterationCount» - 1 . Также стоит отметить, что ваш итератор должен быть подписан; unsigned intне будет работать и, скорее всего, предупредит компилятор.

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

Это становится интересным после замены Math.sqrt (x) на Mymodule.SomeNonPureMethodWithSideEffects (x).

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

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

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

Однако, если вызов функции является библиотечной функцией, которая не constexpr является компилятором, он почти наверняка выполнит ее на каждой итерации, поскольку не может вывести это (если только он не является встроенным и, следовательно, может быть выведен как чистый).

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

Лично я чувствую, что немного более элегантно поместить условие в цикл for, если вы можете, но если оно будет сложным, я запишу его в функцию constexprили inline, или ваши языки будут равносильны намеку на то, что функция чистая и оптимизируемая. Это делает намерение очевидным и поддерживает идиоматический стиль цикла без создания огромной нечитаемой строки. Это также дает проверке состояния имя, если это его собственная функция, поэтому читатели могут сразу увидеть логически, для чего проверка, не считывая ее, если она сложная.