Тонкости оператора switch

[@DemetrNieA]

>>Думаю, теперь понятно, почему после найденного соответствия, выполнение продолжается до первого встретившегося break

А это не было понятно изначально? вроде бы мы видим работу алгоритма по стандарту и только.
Интересна только оптимизация на 3-ке, которую вы разбираете ниже.

[@Fil]

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

[@barker]

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

А в какой реализации switch работает не по стандарту? Тут не только стандарт, а вообще ожидаемое поведение от свича по его определению. Чтобы «узнать поведение» надо знать не больше чем что такое вообще switch во всех таких (скажем, C-подобных) его реализациях. Что именно могло вызвать вопрос то? Вот этот вывод из статьи:

выполнение продолжается до первого встретившегося break.

ведь заведомо известное ожидаемое поведение, не?

[@SVlad]

Полагаю, имелось в виду: «Понятно, каким именно способом стандарт реализован в байткоде».

[@Fil]

Именно. Но, как я написал ниже, это всего лишь небольшое замечание по реализации, а не подведение итогов.

[@Fil]

Возможно, вам показалось, что это полученный вывод? Нет, это очевидная информация, написанная мимоходом. Раздел не об этом.

[@barker]

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

Каков результат работы этого кода?

подразумевает как минимум какую-то неоднозначность поведения или подвох или загадку.

[@Fil]

Да, понял вас. Согласен. Первый пример привел для разминки, чтобы его потом поковырять.

[@Fil]

JLS разве описывает способ реализации switch? JVM да.

[@alexey_uzhva]

Если второй случай и так обрабатывается JIT-ом, то зачем мне сакральное, но бесполезное знание?

[@madkite]

Это философский вопрос… Например в олимпиадном программировании на JIT полагаться не всегда можно.

[@Fil]

Вы не думайте, что благодаря JIT, tableswitch и lookupswitch одинаковы по производительности. JIT, очень старается оптимизировать, (в большинстве случаев лучше человека, и нам нет нужды вникать в эти тонкости) но только там, где это возможно. Например, разница будет явно видна с последовательными и сильно разбросанными ключами. Поэтому да, эти знания представляют только научный интерес.

[@alexey_uzhva]

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

1) Весь остальной код должен быть идеальным, т.к. нет смысла оптимизировать lookupswitch-и, если у вас алгоритм кривой
2) Он все еще работает медленно и нуждается в оптимизации
3) Оптимизация lookupswitch-ей даст хоть какой-то прирост

Не вижу себе реальной практической ситуации, когда эти 3 условия могут встретиться в одной точке.

[@Fil]

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

[@JuniorIL]

Оператор switch в Java? Не, не слышал…

[@Mrrl]

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

Хороший совет. Но вот если после обработки какого-нибудь из этих нескольких ключей нет break… что же, goto внутрь второго switch писать? :)

[@Fil]

У вас вряд ли возникнет такая ситуация на практике. Это очень плохой код :) Но если возникнет, то тут уж по усмотрению, я просто оценил скорость нахождения совпадения.

[@Mrrl]

Думаю, что обработку далёких ключей можно внести в default — тогда структурность почти не нарушится.