что быстрее if или case
If или switch().case. Что быстрее
switch case 1 ИЛИ 2
делаю разбор вводимых команд, некоторые обрабатываются похоже, команды однобуквенные, разбираю.
Решение
В первом случае все if будут проверяться всегда.
Во втором случае все case будут пройдены только при а = 4. Например, если а = 2, то отработает только первый case и мы выйдем по break. При а = 3 отработают два первых case.
Решение
if выполняет столько сравнений, сколько у вас вариантов. switch вероятнее всего сделает двоичный поиск и выполнит число сравнений равное двоичному логарифму от числа вариантов. Если внутре у ней неонка jmp по табличке, то и вовсе в одну команду уложится.
Ну и каждое ветвление награждает вас 50% бонусом к шансу получить неверным предсказанием перехода по башке. Что не лучшим образом сказывается на производительности. Поэтому лучше их без нужды не плодить.
Это ты еще duff device не видел 
——
А вообще все эти рассуждения о скорости не имеют смысла без привязки к конкретному компилятору и его оптимизации. Если хочется адекватных оценок, то берем компилятор, конкретные ключи компиляции, смотрим ассемблер и делаем выводы. Все остальное от лукавого.
при очень разреженном
при case 0 1 2 3 4
скорее всего switch превратится в таблицу переходов
у Evg в блоге была статья на эту тему
если найду кину ссылку
Добавлено через 1 минуту
очень даже распространенная практика «проваливания»
кстати в шарпе её кастрировали и приходится дублировать код
чаще да
но посмотри на код по ссылке
Добавлено через 2 минуты
Ещё неплохой способ «we need to go deeper»:
Статический хеш или switch-case/if-else для выбора
Добрый день. Положим есть такой код:void parseByType(const QString &data, const QString &type) <.
Что быстрее switch(enum) или if else? Что лучше использовать: if\else или switch\case? Ответ выше не совсем корректный, даже учитывая комментарий. Если значения лежат рядом, например: В таком случае компилятор генерирует таблицу переходов (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++ уже умеют. Итак, то, какая из имплементаций скорее, а какая медленнее — это не абсолютное понятие. Вы не должны жертвовать читаемостью кода ради сиюминутной мизерной выгоды. Пишите не «как скорее», а «как правильнее». Расходы на поддержку плохо написанного кода несравнимо больше выгод от микрооптимизаций. Я бывший парень Паскаль, в настоящее время изучаю C#. Мой вопрос заключается в следующем: — Это код ниже быстрее, чем сделать переключатель? какой из них быстрее? Я спрашиваю, потому что моя программа имеет подобную структуру (много, много утверждений «еще если»). Должен ли я превратить их в переключатели? для всего нескольких элементов разница невелика. Если у вас есть много предметов, вы обязательно должны использовать переключатель. Если коммутатор содержит более пяти элементов, он реализуется с помощью таблицы подстановки или хэш-списка. Это означает, что все элементы получают одинаковое время доступа по сравнению со списком 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 аналогичным образом при запуске этот код часто? Прошло уже достаточно времени с момента релиза 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 молодая и вышла только месяц назад. А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные? Например, есть примерно след. участок кода: Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае? Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже? Здравствуйте, Аноним, Вы писали: А>Приветствую. А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные? А>Например, есть примерно след. участок кода: А> лет пять назад дизассемблировал подобный сниппет. в Release сборке студия данную последовательность if’ов преобразует в switch. (его ассемблерное представление, разумеется) Здравствуйте, Аноним, Вы писали: А>Приветствую. А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные? А>Например, есть примерно след. участок кода: А> А>Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае? А>Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже? А>Использую MS-компилятор. Помнится даже на баше был гдето ответ. Тут чтоле Здравствуйте, Аноним, Вы писали: А>Приветствую. А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные? Это существенно зависит от распределения значений входных данных. Если какой-либо зависимости в значениях value нет, то switch вполне может быть лучшим вариантом. Если же значение a или b встречаются значительно чаще (например в 95% и 4% случаев соответственно), то if может существенно превосходить в скорости switch. Для уверенности, что компилятор нас правильно понял, ещё бывает полезно обернуть условие (value == a) во что-то подобное __builtin_expect(value == a, 1) или __assume(value == a). Где __builtin_expect и __assume — соответствующие подсказки оптимизатору. А>Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже? Универсального ответа тут нет. Но что тебе мешает просто посмотреть сгенерированный код самому? Для того, чтобы сказать, что получился одинаковый код, можно же даже не знать ассемблера. Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит). Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать В результатах конечно простыня еще та. Как видите — вариант с if практически сразу потерял свои позиции и под конец разница с switch на порядок. А вот результаты сборки с оптимизацией мгновенно ставят все на свои места Здравствуйте, Sheridan, Вы писали: S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит). На мой взгляд это совершенно бессмиысленное заниятие. Во-первых, часто компилятор для двух конструкций генерирует один и тот же ассемблерный код, если конструкции не сложные. Во-вторых, не каждый if можно заменить предложением switch. И, в-третьих, скорость ни одной программы не страдает от того, используете ли вы if или swicth. Здравствуйте, Сыроежка, Вы писали: С>На мой взгляд это совершенно бессмиысленное заниятие. Во-первых, часто компилятор для двух конструкций генерирует один и тот же ассемблерный код, если конструкции не сложные. Во-вторых, не каждый if можно заменить предложением switch. И, в-третьих, скорость ни одной программы не страдает от того, используете ли вы if или swicth. Ребе, ну человек задал конкретный вопрос — я на него дал не просто ответ, а вполне себе даже исследование. Здравствуйте, Sheridan, Вы писали: S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит). S>Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать Тест плохой. Вы сравнили скорость работы двух пустых функций. Здравствуйте, Sheridan, Вы писали: S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит). S>Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать — оптимизатор г++ слишком хорош для данного случая, а я писал на работе, слишком хотел домой и не подумал об этом. Посыпаю голову пеплом, и все такое. Результат без оптимизаций и результат с оптимизациями
Может кто нибудь знает,какая конструкция лучше в плане производительности: 1) enum eЧто быстрее, вложенные REPLACE или функция с CASE на va?
Здравствуйте форумчане. Имеется база с приличным количеством записей, порядка миллиона. Задача в.if \ else vs. switch \ case в C#
3 ответа 3
Является ли» else if «быстрее, чем»switch() case»? [дубликат]
14 ответов:
Match/case vs If/else. Сравниванием скорость работы операторов в Python 3.10
Начинаем
Вывод
Что быстрее if или case
От: LaptevVV Дата: 05.02.12 15:31 Оценка: 1 (1) 
От: potapov.d Дата: 05.02.12 15:48 Оценка: 
От: watch-maker Дата: 08.02.12 12:36 Оценка: 1 (1)
А>Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае?
Это связано с особенностью блока предсказания ветвлений процессора. Последовательные if позволяют ему «обучаться» на входных данных и лучше предсказывать нужную ветку программы. В то же время switch, если компилятор сделал из него таблицу и косвенный переход, будет справляться с этой задачей значительно хуже.
Например, для архитектур x86 и x86-64 подробнее об switch-против-if можно прочитать в «Intel® 64 and IA-32 Architectures Optimization Reference Manual».
Ну и вообще, в таких случаях может быть эффективна гибридная схема: 
От: Sheridan Дата: 10.02.12 13:16 Оценка:
Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
Ну, по коду думается мне будет понятнее.
Результаты неоптимизированной сборки: 
От: Сыроежка Дата: 10.02.12 13:23 Оценка: От: Sheridan Дата: 10.02.12 13:28 Оценка:
С написанными тобой буквами я то согласен и так. Только вот было интересно их както подтвердить
Подтвердил таки? От: watch-maker Дата: 10.02.12 13:46 Оценка:
S>Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
S>Ну, по коду думается мне будет понятнее.
Например, gcc43 просто преобразует функцию test_if в такую: 
От: batu Дата: 10.02.12 14:08 Оценка:
S>Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
S>Ну, по коду думается мне будет понятнее. От: batu Дата: 10.02.12 14:10 Оценка: От: Sheridan Дата: 10.02.12 15:51 Оценка: От: Sheridan Дата: 10.02.12 16:29 Оценка:
В общем я нагрузил алгоритм еще одной функцией, которая принимает в себя число-счетчик цикла и на его основе считает всякую фигню. Ну типа полезную работу делает.
Также я на отдельно замеряю среднее количество тиков работы этой функции и вычитаю это потом из результата.