оператор выбора или перспектива эффективности оператора "if" [дубликат]
5 ответов
Думаю, главное - писать код как можно яснее. Подобные микрооптимизации не должны быть в центре внимания.
Например, если у вас есть что-то вроде этого:
if (age == 10) {
// ...
} else if (age == 20) {
// ...
} else if (age == 30) {
// ...
} else if (age == 40) {
// ...
}
Тогда будет понятнее использовать оператор switch:
switch (age) {
case 10:
// ...
break;
case 20:
// ...
break;
case 30:
// ...
break;
case 40:
// ...
break;
}
Опять же, я бы сосредоточился на упрощении чтения и поддержки кода, а не на повышении эффективности на наносекундном уровне .
Если бы у вас была очень большая цепочка операторов if else, то да, вы могли бы почувствовать разницу. Но очень нереально, что вы когда-нибудь напишете такую длинную цепочку ifelse. И даже если бы вы это сделали, все равно очень маловероятно, что именно здесь будет ваше узкое место в производительности.
Сначала напишите свой код так, чтобы он был удобочитаемым, и позвольте профилировщику руководствоваться вами, когда возникает необходимость в оптимизации производительности.
- Да
- Нет, это часть дизайна вашей программы. Но вы должны подумать, не может ли переопределяемый метод быть еще лучшим решением, с семейством типов.
Любой компилятор сделает таблицу переходов, если сможет убедиться, что значения достаточно компактны. (Я сомневаюсь, что в данном случае они компактны, поскольку кратны 10.)
Это микрооптимизация. Микрооптимизация имеет смысл, только если вы знаете, что она имеет смысл. Как правило, в других местах есть более важная "рыба для жарки" в виде вызовов функций, без которых можно обойтись. Однако, если вы уже настроили весь код, и профилирование показывает, что значительная часть времени (около 10% или более) уходит на эти операторы IF (а не на их содержимое), то это поможет. Это может произойти, например, в интерпретаторе байт-кода.
Добавлено: Еще одна причина, по которой мне нравится использовать switch - даже если он не делает таблицу переходов - при просмотре кода в отладчике он переходит непосредственно к нужному случаю, а не заставляет меня перебирать множество ложных if операторов. Это облегчает отладку.
Наверное, неважно. Байт-код - это просто «транспортный формат» для JVM. То, что происходит внутри JVM, сильно отличается от представления байт-кода. (Пример: байт-код не предлагает операции с плавающей запятой, поэтому float + - * /% float выполняется как двойные операции, а затем результат возвращается к float. То же самое верно для byte / short, они преобразуются в int, а затем обратно .) Но для коммутатора это два формата байт-кода, в одном уже есть таблица переходов. Но честно: я бы выбрал формат, который лучше всего подходит вам и читателю вашей программы. Все остальное сделает JVM. Если вы слишком умны, вы, возможно, не поймете JVM, и, в конце концов, программа будет работать медленнее.
«Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол» Д. Кнут