Что быстрее case или if
Эстетическая красота: Switch vs If
Вводная
Немного нюансов
Речь ниже пойдет о сравнении оператора switch и его конкретной реализаций на языке Java и операторами if в виде оппонентов этой конструкции. О том, что у оператора switch имеется туз в рукаве — производительность (за редким исключением), пожалуй, знает каждый и этот момент рассматриваться не будет — так как крыть его нечем. Но все же, что не так?
1. Многословность и громоздкость
Среди причин, отталкивающих меня от использования оператора switch — это многословность и громоздкость самой конструкции, только взгляните — switch, case, break и default, причем опускаю за скобки, что между ними, наверняка, еще встретится return и throw. Не подумайте, что призываю не использовать служебные слова языка java или избегать их большого количества в коде, нет, лишь считаю, что простые вещи не должны быть многословными. Вот небольшой пример того, о чем говорю:
Итого для меня: switch/case/default VS if.
Если спросить, кому какой нравится больше код, то большинство отдаст предпочтение 1ому варианту, в то время как по мне, он — многословный. Речь о рефакторинге кода здесь не идет, все мы знаем, что можно было бы использовать константу типа EnumMap или IdentityHashMap для поиска списка по ключу channel или вообще убрать нужные данные в сам Channel, хотя это решение дискуссионное. Но вернемся.
2. Отступы
Возможно в академических примерах использование оператора swicth — это единственная часть кода, но тот код, с которым приходится сталкиваться, поддерживать — это более сложный, обросший проверками, хаками, где-то просто предметной сложностью код. И лично меня, каждый отступ в таком месте напрягает. Обратимся к ‘живому’ примеру (убрал лишнее, но суть осталась).
Итого для меня: 5 отступов VS 2.
Но опять, кому какой нравится вариант? Большинство отдаст предпочтение getReference1.
Отдельно стоит отметить, что количество отступов еще зависит от выбранного стиля форматирования кода.
3. Проверка на null
Если используется оператор switch со строками или енумами параметр выбора необходимо проверять на null. Вернемся к getTypes примерам.
Итого для меня: лишний код.
Даже если Вы абсолютно уверенны сейчас в том, что null ‘не придет’, это абсолютно не значит, что так будет всегда. Я проанализировал корпоративный багтрэк и нашел этому утверждению подтверждение. Справедливости ради стоит отметить, что структура кода выраженная через if не лишена этой проблемы, зачастую константы для сравнения используются справа, а не слева, например, name.equals(«John»), вместо «John».equals(name). Но в рамках данной статьи, по этому пункту, хотел сказать, что при прочих равных, подход со switch раздувается проверкой на null, при if же проверка не нужна. Добавлю еще, что статические анализаторы кода легко справляются с возможными null-багами.
4. Разношерстность
Очень часто, при длительном сопровождении кода, кодовая база раздувается и можно легко встретить код, похожий на следующий:
Итого для меня: разный стиль.
Раньше был ‘чистенький’ switch, а теперь switch + if. Происходит, как я называю, смешение стилей, часть кода ‘выбора’ выражена через switch, часть через if. Разумеется никто не запрещает использовать if и switch вместе, если это не касается операции выбора/под выбора, как в приведенном примере.
5. Чей break?
При использовании оператора switch, в case блоках может появиться цикл или на оборот, в цикле — switch, со своими прерываниями процесса обработки. Вопрос, чей break, господа?
Итого для меня: читаемость кода понижается.
Если честно, встречались и куда более запутанные примеры кода.
6. Неуместность
В java 7 появилась возможность использовать оператор switch со строками. Когда наша компания перешла на java 7 — это был настоящий Switch-Бум. Может по этому, а может и по другой причине, но во многих проектах встречаются похожие заготовки:
Итого для меня: появляются неуместные конструкции.
7. Гламурный switch под аккомпанемент хардкода
Немного юмора не помешает.
Заключение
Я не призываю Вас отказываться от оператора switch, местами он действительно хорош собой и лапша из if/if-else/else та еще каша. Но черезмерное его использование где ни попадя, может вызывать недовольство у других разработчиков. И я один из них.
Отдельно хотелось отметить, что c точки зрения понимания кода, у меня нет никаких проблем с switch/case — смысл написанного ясен, но вот с точки зрения восприятия эстетической красоты — есть.
И напоследок. Используйте то, что Вам приходится по душе, опуская за скобки навязанные мнения, главное, чтобы Ваш код был простым, рабочим, красивым и надежным. Всего хорошего.
if \ else vs. switch \ case в C#
Что лучше использовать: if\else или switch\case?
3 ответа 3
Ответ выше не совсем корректный, даже учитывая комментарий.
Если значения лежат рядом, например:
В таком случае компилятор генерирует таблицу переходов (jump table) (IL-код):
Как видно, «дырки» заполнились переходами за конец конструкции switch : IL_009a
Если расстояние между значениями слишком большое для построение одной таблицы, компилятор может разделить их на 2+ таблицы. Например:
Посмотрим что будет в общем случае. Я взял 20 случайных чисел:
В таком случае компилятор их сортирует, и ищет бинарным поиском:
Дополнение для String :
Я попытался создать очень большой switch на 60 строк, но ничего не изменилось.
Оба условных оператора работают с одинаковой скоростью. Так как на уровне машинных команд они преобразуются в одни и те же инструкции.
Выбирать имеет смысл только по вкусу и по задаче.
switch может работать только с одной переменной. У if таких ограничений нет.
На мой взгляд, язык C# слишком высокоуровневый для такого рода оптимизаций.
Пишите читаемый код 😉
Вы задаётесь неправильным вопросом.
Если ваша задача — ускорить вашу программу, то решением этой задачи никогда не будет «заменить свитч на последовательность ифов» или наоборот. Ускорение программы проводится на уровне используемых алгоритмов и структур данных.
Тот факт, что один или другой вариант в тех или иных условиях, на той или иной версии компилятора выполняется на несколько наносекунд быстрее, не стоит потраченных на него байт текста.
Во-первых, вы должны помнить, что ваша главная задача — не выиграть 10 тактов процессора (несчастное переключение контекста стоит намного больше!), а сделать вашу программу понятной. Поэтому вы должны использовать switch там, где это прибавляет читаемости коду, там, где это соответствует тому, что именно вы хотите сказать этим кодом. И использовать if там, где это лучше отражает вашу мысль.
Ну и во-вторых, то, что на одной версии компилятора один из методов выражения одной и той же идеи компилируется в более быстрый код, чем другой метод — штука временная и преходящая. Помните, что в C++ сначала рекомендовалось возвращать значения по ссылке для скорости, а затем пришёл тренд «want speed? pass by value!», и наверняка это поменялось сейчас ещё раз.
Поскольку код имеет одинаковый смысл, то в любом из его вариантов рано или поздно он будет компилироваться в одно и то же. JIT-компилятор C# покамест не генерирует одинаковый объектный код для этих двух случаев, а вот компиляторы C++ уже умеют.
Итак, то, какая из имплементаций скорее, а какая медленнее — это не абсолютное понятие.
Вы не должны жертвовать читаемостью кода ради сиюминутной мизерной выгоды. Пишите не «как скорее», а «как правильнее». Расходы на поддержку плохо написанного кода несравнимо больше выгод от микрооптимизаций.
Match/case vs If/else. Сравниванием скорость работы операторов в Python 3.10
Прошло уже достаточно времени с момента релиза Python версии 3.10. Самым главным и самым ожидаемым было введение оператора match/case (он же pattern matching).
Однако далеко не всем разработчикам из нашего комьюнити зашел данный оператор. Свидетельствуют этому даже комментарии под статьями на хабре (статья 1, статья 2), которые были посвящены match/case.
На мой взгляд, новый оператор упрощает жизнь разработчикам, принимая на себя работу с проверкой типов данных или принадлежностью определенному классу. Но, как мы все знаем, зачастую за крутые фичи, введенные в язык, программисту приходится платить. В данной статье я хотел бы осветить тему производительности оператора match/case и сравнить его с обычным if/else.
Начинаем
Создадим несколько простых проверок данных, получаемых в функции create_rnd_data:
Самое интересное: при помощи модуля timeit проверим время, за которое в среднем будет выполняться каждая функция. Проведём 1000 испытаний каждой функции:
Зачем делаются проверки isinstance в if/else?
Хммм… В 3.8 раза скорость выполнения match/case оказалась медленнее, чем скорость if/else. Но не будем загадывать наперед, может быть, match/case окажется быстрее при работе с более сложными структурами, например, при проверке словарей.
Создадим некоторый список словарей:
Проверим, как поведут себя if/else и match/case при работе со словарями:
В 5 раз оператор match/case уступил по скорости if/else. Рано делать выводы, проверим работу с еще более сложными структурами, например, создадим свой класс и выполним те же проверки:
Вывод
Я не стал проверять оператор match/case на списках, кортежах, множествах и других структурах, не стал нагружать сложными условиями, так как, думаю, очевидно можно сделать пару выводов:
Если в приложении есть проверки на формы ввода, либо проверки if/else слишком большие, но проверки выполняются не очень часто (например, при клике пользователя на кнопку), то оператор match/case может стать хорошей альтернативой if/else, так как он сочетает в себе много хороший функций (см предыдущие статьи во введении);
Будем надеяться и ждать оптимизацию match/case, так как версия Python 3.10 молодая и вышла только месяц назад.
Является ли» else if «быстрее, чем»switch() case»? [дубликат]
Я бывший парень Паскаль, в настоящее время изучаю C#. Мой вопрос заключается в следующем:
— Это код ниже быстрее, чем сделать переключатель?
какой из них быстрее?
Я спрашиваю, потому что моя программа имеет подобную структуру (много, много утверждений «еще если»). Должен ли я превратить их в переключатели?
14 ответов:
для всего нескольких элементов разница невелика. Если у вас есть много предметов, вы обязательно должны использовать переключатель.
Если коммутатор содержит более пяти элементов, он реализуется с помощью таблицы подстановки или хэш-списка. Это означает, что все элементы получают одинаковое время доступа по сравнению со списком if:s, где последний элемент занимает гораздо больше времени, поскольку он должен сначала оценить каждое предыдущее условие.
99,99% времени, вы не должны заботиться.
эти виды микрооптимизации вряд ли повлияют на производительность вашего кода.
кроме того, если вам нужно было заботиться, то вы должны делать профилирование производительности на вашем коде. В этом случае выяснение разницы в производительности между корпусом коммутатора и блоком if-else было бы тривиальным.
Edit: для ясности: реализовать любой дизайн понятнее и более ремонтопригодны. Обычно при столкновении с огромным переключателем или блоком if-else решение заключается в использовании полиморфизма. Найдите поведение, которое изменяется, и инкапсулируйте его. Мне приходилось иметь дело с огромным, уродливым кодом switch case, как это раньше, и, как правило, это не так сложно упростить. Но о, так приятно.
результаты показывают, что оператор switch выполняется быстрее, чем лестница if-else-if. Это связано с возможностью компилятора оптимизировать оператор switch. В случае лестницы if-else-if код должен обрабатывать каждый оператор if в порядке, определенном программистом. Однако, поскольку каждый случай в операторе switch не полагаясь на более ранние случаи, компилятор может переупорядочить тестирование таким образом, чтобы обеспечить самое быстрое выполнение.
еще одна вещь, чтобы рассмотреть: это действительно узкое место вашего приложения? Бывают крайне редкие случаи, когда оптимизация такого рода действительно требуется. Большую часть времени вы можете получить намного лучшие ускорения, переосмыслив свои алгоритмы и структуры данных.
Я бы сказал, что переключатель-это путь, он быстрее и лучше практикуется.
существуют различные ссылки, такие как (http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx), которые показывают тестовые тесты, сравнивающие эти два.
не должно быть трудно проверить, создать функцию, которая переключается или ifelse между 5 числами, бросить rand (1,5) в эту функцию и цикл, что несколько раз во время синхронизации его.
переключатель находится, как правило, быстрее, чем длинный список «Если», потому что компилятор может генерировать таблицы переходов. Чем длиннее список, тем лучше операторе switch серии операторов if.
гораздо более важными, чем преимущества производительности коммутатора (которые относительно невелики, но стоит отметить) являются проблемы читаемости.
Я для одного нахожу оператор switch чрезвычайно ясным в намерениях и чистых пробелах, по сравнению с цепочками ifs.
Я не уверен, но я считаю, что скорость одной или другой меняется в зависимости от языка программирования, который вы используете.
Я обычно предпочитаю использовать переключатель. Таким образом, код является простым для чтения.
технически, они дают точно такой же результат, поэтому они должны быть оптимизируемы в значительной степени таким же образом. Однако есть больше шансов, что компилятор оптимизирует случай коммутатора с таблицей переходов, чем ifs.
Я говорю об общем случае. Для 5 записей среднее число тестов, выполненных для ifs, должно быть меньше 2,5, если вы заказываете условия по частоте. Вряд ли узкое место, чтобы написать домой, если только в очень плотном петля.
switch обычно переводится в таблицу поиска компилятором, если это возможно. Таким образом, поиск произвольного случая-Это O(1), вместо того, чтобы фактически делать несколько сравнений случаев, прежде чем найти тот, который вы хотите.
Так что во многих случаях if / else if цепи будет медленнее. Однако в зависимости от частоты, с которой ваши случаи поражаются, это может не иметь никакого значения.
короткий ответ: оператор Switch быстрее
оператор if вам нужно два сравнения (при запуске кода примера) в среднем, чтобы добраться до правильного предложения.
оператор switch среднее число сравнений будет одним независимо от того, сколько разных случаев у вас есть. Компилятор / виртуальная машина сделает «таблицу поиска» возможных параметров во время компиляции.
могут ли виртуальные машины оптимизировать оператор if аналогичным образом при запуске этот код часто?
Что быстрее и лучше, Switch Case или if else if?
8 ответов
Какой из них лучше когда производительность принимается во внимание случай if else if или switch Дубликат: есть ли какая-либо существенная разница между использованием if/else и switch-case в C#?
У меня есть три условия для сравнения. Какой из них быстрее между следующими двумя? Пожалуйста, покажите мне. Спасибо всем! If var = 1 then Command for updating database ElseIf var = 2 then Command for updating database ElseIf var = 3 then Command for updating database EndIf и Select Case var Case.
Случай, когда switch на самом деле дает вам преимущество в производительности, заключается в том, что переменная часть является вызовом функции:
Тогда some_func() вызывается только один раз, когда с
Но на самом деле это будет иметь значение только в том случае, если вы захотите сократить микросекунды для функции, которая будет вызываться тысячи раз.
Общее правило- использовать switch всякий раз, когда число условий превышает 3 (для удобства чтения).
if / else if / else является более гибким (следовательно, лучше), но switch немного быстрее, потому что он просто вычисляет условие один раз, а затем проверяет вывод, в то время как if должен делать это каждый раз.
Из того, что я прочитал, я могу подвести итог, Switch case определяется реализацией, но в основном определяется как таблица переходов Корпус переключателя делает код более читабельным Переключатель работает быстрее, чем if/elseif (?) Рассмотрим случай,когда у меня есть 300 + переключателей. Я.
Возможный Дубликат : Если/еще и Переключатель У меня здесь есть два кода, я просто хотел спросить, какой из них лучше с точки зрения удобочитаемости(легкость написания кодов) и с точки зрения читаемости (легкость понимания кодов). распределительный ящик : import java.io.*; public class Quarter<.
Это зависит от использования. Если у вас есть статус fxp (онлайн, в отъезде, dnd, оффлайн. ), лучше использовать переключатель.
Но если ты хочешь чего-то подобного
его лучше использовать, если иначе.
Они также указывают на вложенные операторы if, которые имеют гораздо больше смысла, а также обеспечивают гораздо лучшие результаты.
вложенный if/elseif === : 0.25623297691345 (вложенный IF)
переключатель / корпус: 0.33157801628113 (корпус переключателя)
if/elseif с === : 0.45587396621704 (FLAT IF)
только если с === : 0.45587396621704 (только если)
Я верю, что компилятор превратит их в очень похожий или, возможно, даже идентичный код в конце дня.
Если вы не делаете что-то странное, не пытайтесь выполнить оптимизацию для компилятора.
Кроме того, время разработчика, как правило, более важно, чем время выполнения (за исключением игр), поэтому лучше сделать его более читаемым и доступным для обслуживания.
если вам нужно сделать 1,2 случая, например, если/иначе, если/иначе
Похожие вопросы:
код if ([@[@1,@2,@3] containsObject:@(section)]) < return 10; >else if ([@[@0,@4] containsObject:@(section)]) < return 15; >else < return 0; >&& switch (section) < case 0: return 15; case.
Какой из них лучше когда производительность принимается во внимание случай if else if или switch Дубликат: есть ли какая-либо существенная разница между использованием if/else и switch-case в C#?
У меня есть три условия для сравнения. Какой из них быстрее между следующими двумя? Пожалуйста, покажите мне. Спасибо всем! If var = 1 then Command for updating database ElseIf var = 2 then Command.
Из того, что я прочитал, я могу подвести итог, Switch case определяется реализацией, но в основном определяется как таблица переходов Корпус переключателя делает код более читабельным Переключатель.
Возможный Дубликат : Если/еще и Переключатель У меня здесь есть два кода, я просто хотел спросить, какой из них лучше с точки зрения удобочитаемости(легкость написания кодов) и с точки зрения.
Мне нужно проверить небольшую часть логики, и я был бы очень признателен, если бы кто-то мог дать мне ценный вклад. У меня есть два способа проверить свою логику, и я хочу знать, какой из них более.
У меня есть этот чек if else : var aItem: CGFloat = 0 if item == 0 < aItem = 457 >else if item == 1 < aItem = 576 >else if item == 2 < aItem = 758 >print(aItem) Я хочу заменить этот фрагмент кода.