Еще “если” быстрее, чем “переключатель () случай”? [дубликат]

ArrayList<student> studentsListCopy = new ArrayList<student>();

for(int i=0;i<studentList;i++)
{
   studentsListCopy.add(studentList[i])
}

Возможно, вы искали что-то подобное?

344
задан Community 23 May 2017 в 02:10
поделиться

13 ответов

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

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

576
ответ дан 23 November 2019 в 00:31
поделиться

Краткий ответ: оператор Switch быстрее

Оператор if требует двух сравнений (при запуске кода примера) в среднем, чтобы добраться до правильной статьи.

В операторе switch среднее число сравнений будет равно одному, независимо от того, сколько у вас различных случаев. Компилятор / ВМ создаст «таблицу поиска» возможных опций во время компиляции.

Могут ли виртуальные машины оптимизировать оператор if подобным образом, если вы часто запускаете этот код?

3
ответ дан 23 November 2019 в 00:31
поделиться

switch обычно переводится компилятором в таблицу поиска, если это возможно. Таким образом, поиск произвольного случая - это O (1), вместо того, чтобы на самом деле сделать несколько сравнений, прежде чем найти тот, который вам нужен.

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

4
ответ дан 23 November 2019 в 00:31
поделиться

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

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

5
ответ дан 23 November 2019 в 00:31
поделиться

Не должно быть сложно чтобы протестировать, создайте функцию, которая переключает или ifelse между 5 числами, бросает rand (1,5) в эту функцию и зацикливает ее несколько раз во время синхронизации.

7
ответ дан 23 November 2019 в 00:31
поделиться

Я бы сказал, что смена - это путь, он быстрее и эффективнее.

Там Существуют различные ссылки, такие как ( http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx ), которые показывают сравнительные тесты, сравнивающие их.

8
ответ дан 23 November 2019 в 00:31
поделиться

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

14
ответ дан 23 November 2019 в 00:31
поделиться

Полагая эту оценку производительности , корпус коммутатора работает быстрее.

Это вывод :

Результаты показывают, что оператор switch выполняется быстрее, чем лестница if-else-if. Это связано со способностью компилятора оптимизировать оператор switch. В случае лестницы if-else-if код должен обрабатывать каждый оператор if в порядке, определенном программистом. Однако, поскольку каждый случай в операторе switch не опирается на более ранние случаи, компилятор может переупорядочить тестирование таким образом, чтобы обеспечить максимально быстрое выполнение.

27
ответ дан 23 November 2019 в 00:31
поделиться

Почему вас это волнует?

99,99% времени вам не нужно.

Такие микрооптимизации вряд ли повлияют на производительность вашего кода.

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

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

168
ответ дан 23 November 2019 в 00:31
поделиться

Switch обычно быстрее, чем длинный список ifs, потому что компилятор может генерировать таблицу переходов. Чем длиннее список, тем лучше оператор switch по сравнению с рядом операторов if.

6
ответ дан 23 November 2019 в 00:31
поделиться

Поскольку оператор switch выражает то же намерение, что и ваша , если / else цепочка, но в более ограниченном, Формальным образом, ваша первая догадка должна заключаться в том, что компилятор сможет оптимизировать его лучше, поскольку он может сделать больше выводов об условиях, помещенных в ваш код (т. е. только одно состояние может быть истинным, сравниваемое значение является примитивным типом). и т. д.) Это довольно безопасная общая истина, когда вы сравниваете две подобные языковые структуры для производительности во время выполнения.

2
ответ дан 23 November 2019 в 00:31
поделиться

Far more important than the performance benefits of switch (which are relatively slight, but worth noting) are the readability issues.

I for one find a switch statement extremely clear in intent and pure whitespace, compared to chains of ifs.

5
ответ дан 23 November 2019 в 00:31
поделиться

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

Обычно я предпочитаю использовать переключатель. Таким образом код будет проще читать.

5
ответ дан 23 November 2019 в 00:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: