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


Тест идет около 15 минут, поэтому просьба проявить терпение. В результатах присутствует 4 метрики

•  DefinedIf -- Среднее время работы условий на массиве 
•  RandomIf -- Среднее время работы условий на случайных данных
•  DefinedSw -- Среднее время работы switch на массиве 
•  RandomSw -- Среднее время работы switch на случайных данных

 

Случайные данные используются для того, чтобы немного спутать Advanced Branch Prediction

В ответах просьба указать выхлоп, ось и ваш CPU

Мои результаты
Java: Java™ SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot™ Server VM (build 14.0-b16, mixed mode)
OS: Ubuntu 9.04
CPU: Core™2 Duo CPU     P8600  @ 2.40GHz



Это сообщение отредактировал(а) Royan - 1.9.2009, 18:27

как то раз я декомпилировал свой код (потерял исходники) так в нем увидел что при компиляции мои ифы были заменены на свитчи, и многие циклы были изменены на while(true) с условием на брик внутри

Ну учитывая наличие достаточно неплохого JIT, не думаю что там будет какая-то существенная разница.

LSD, Ну речь о разнице в 4,5% на моем примере. Положим, что в приложении данные конструкции используются в каком-нибудь высоконагруженном месте, тогда эти 4,5% весьма интересны

Вообще-то тест несостоятелен по двум причинам:
- он искусственный;
- вы используете массив int, операции над которыми в jvm хорошо-оптимизированы.

И еще.. сравнивать if с switch - то же самое что сравнивать сладкое и длинное.
Как говорилось еще в альма-матер: switch - это искусственная конструкция, оптимизированная  для работы с целыми числами.
Как мне помнится, в Java Language Specification и Java VM specification придерживаются тех же принципов. Хотя, если есть желание - можете javap'нуть код и посмотреть на сгенеренные команды (и посчитать какой выигрыш в инструкциях будет - опять же, если есть желание и свободное время).

Это сообщение отредактировал(а) revenforv - 1.9.2009, 16:45

Как бы вы его модифицировали, чтобы приблизить к реальным условиям? Вы же не будете спорить с тем, что операции if(){} else if(){} используются довольно часто. Цель данного теста проверить действительно ли switch может оказать быстрее чем if при прочих равных условиях.


В java switch работает в т.ч. с перечислениями можно попробовать переписать тест с enum'ами и сравнить, может быть к ночи ближе перепишу.

  Да я то с вами полностью согласен, просто до сих пор помнится, как меня заставили на 3 курсе переписывать курсовую на C, в которой в for'е проверялось логическое условие, а не счетчик по массиву. Пришлось все for'ы переделывать в while.  

Ну это так - отступление от темы.. а вообще - я почитаю jls и скажу, что там написано на этот счет.

Это сообщение отредактировал(а) revenforv - 1.9.2009, 17:08

Проиграете. Думаю, многие этим баловались. Я тоже когда-то экспериментировал. Теперь не заморачиваюсь ловлей блох и делаю как нагляднее. Есть ведь еще варианты. Например, в мап кладутся обьекты - екзекюторы. И осуществляется выбор нужного обьекта по ключу за один шаг. Разновидность этого подхода - положить экзекюторы в массив и извлекать по целочисленному индексу (в вашем эксперименте это temp). 
Выжимать 4% не очень благодарное занятие. Со временем убунту поменяется на шмубунту, выйдет новая версия java и все может быть наоборот. А для клиентских программ, бегающих в совершенно разных условиях, это еще более неопределенно. Ну и любой тюнинг производительности обычно идет в ущерб наглядности программы. Если количество пользователей системы возрастает и сервера не справляются, то масштабирование, подключение новых компьютеров, является более радикальным выходом.    

Это сообщение отредактировал(а) COVD - 1.9.2009, 17:43

Вообще некузяво бы еще версию java указывать







Добавлено @ 17:43
Да еще, тест строго однопоточен - второе ядро вообще не задействовано было

Это сообщение отредактировал(а) fixxer - 1.9.2009, 17:44

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





Машина: Intel Xeon E5410 2.33 GHz, 2 GB RAM, Windows XP.

Понимаю. У меня желание написать тест родилось после того как я столкнулся в коде с необходимостью проверки внутреннего типа persistent cache'а. В зависимости от этого типа производилось то или иное действие. Тут нет проблемы что-то за экзекютить, к тому же для такой задачи больше подходит решение с ThreadPoolExecutor'ом

Экзекютор не в смысле задания, которое ставится в очередь и выполняется в отдельном потоке. Если внутри каждого if (или case) больше одной строчки кода, то может быть удобным оформить их методами разных обьектов (например, run() в анонимных Runnable ). Компактнее и возможно нагляднее будет выглядеть код. А выполняться все будет в том же потоке. 
Возможно, правильнее называть эти обьекты хэндлерами или процессорами.

Это сообщение отредактировал(а) COVD - 1.9.2009, 18:58

Работало на одном ядре

Попробовал дома:





  

Добавлено через 12 минут и 21 секунду