Eu trabalho com C embarcado pra DSP de controle de motor. A otimização do compilador no meu caro praticamente dobra o desempenho do código. Eu rodo um algoritmo de controle que sem otimização consegue rodas só em 12KHz, quando liga as otimizações globais ele chega a rodar em 25 KHz. Fora isso tem que tomar cuidado com a otimização do embarcado que ele pode mudar as funções de ponto flutuante e fazer uns arredondamentos e simplificações em interrupções que podem dar problema. Por isso é importante pelo menos ter uma ideia do que acontece por baixo dos panos!
Cuidado carinha, não fala de embarcado aqui se não a galera vem surtar falando que é a mesma coisa que programar pra PC que otimização não faz diferença e tal que os embarcados hoje são os processadores mais eficientes e potentes já criados pela humanidade. 🤣😂🤣😂
Excelente, trabalho com TA ou também conhecido como CLP, também as vezes enchemos de coisas e o ciclo de Scan sobe lá na galáxia e fica inviável o controle do processo. Por isso que quando criamos e alteramos algum software já pensamos na otimização.
Você é a ÚNICA pessoa que eu vi que explica o porquê do switch ser mais rápido. Eu realmente não achei explicação boa e acurada igual ao seu video. Muito bom
interessante! pior que já teve umas 2x que eu fiz esse teste em projetos pessoas e para mim o swtich/case apresentou uma performance levemente melhor (javascript)
Ih, javascript é a maior incognita da face da terra. TUDO depende. Tu usou console.log? Já não é a performace real, qual interpretador foi usado? Se for navegador cada um interpreta do seu jeito, se for node cada versão vem embarcada com um interpretador diferente. Se for em TypeScript ao inves de Javascript a performace vai piorar umas 500x pq o transpilador vai fazer um MONTE de merda no codigo JS e por ai vai...
@@thenub8532 Mas isso não tem nada a ver mano. Só porque javascript não é tão performático não significa que ele tenha que uso isso como desculpa pra fazer o código de qualquer jeito kkkkk
Entramos numa discussão sobre performace entre Switch e IF ELSE, e terminamos com uma discussão em aberto entre o que é mais legível: Switch ou IF ELSE (e sei que tem gente que odeia um ou outro)
nunca gostei de if else... preferia criar if's soltos... com o tempo deduzi q if else era mais performático (pq no caso de if's soltos, a máquina verifica tudo)... nn gosto de switch pq axo xato de editar (em c#)... enfim...
Interessante. Switch case deve ser usado quando se tem muitas opções de entrada, se usar if else nessas situações o compilador leva muito tempo pra executar o programa. Ja o if else se usa nas situações onde se tem poucas opções ou situações booleanos( verdadeiro ou falso)
Se me lembro direito, ARM aloca a tabela de saltos no bloco da função e tem instrução que indexa a tabela com um offset e faz salto no mesmo ciclo utilizando o program counter como registrador de uso geral , então geralmente switch case é mais rápido e ocupa menos espaços em arquitetura ARM cortex-m. O Else If em ARM sempre faz uma comparação e salta depois de verificar o registrador de status, se tiver sorte você vai ter um salto em 2 ciclos, mas se tiver azar e o branch predctior falhou você leva um flush e perde os três estágio de pipeline. Mas com RISC-V e outros processadores super escalares as coisas mudam e geralmente não tem diferença entre os dois, porque mesmo com otimização de compilação ultra mega cosmic vegana pica, tudo depende do humor do escalonador no ciclo do salto. Em x86_64 é ainda pior, já que geralmente esses processadores tem de 11 a 22 estágios de pipelines que podem executar instruções fora de ordem, o branch predctior pode fazer o salto três ciclos antes da comparação do Else If ou um Else If no final do bloco pode ser processado no começo porque o processador quis e ele quer que se dane a sua opinião porque ele não liga para você 😐
É muito difícil o problema de performance ser o IF, além que se tem uma caralhada de if, é melhor usar polimorfismo ou um map com valor uma função anônima
pessoalmente amo switch por que fica mt clean, sempre que o código involve interface de comunicação com usuário aparece bastante if else, switch sempre salva muitoo
Parabéns pelo vídeo, eu confesso que em casos assim eu não ligo pra performance, pq se não eu ia começar a mexer com bitwise, gosto mais de usar o swirch por parecer mais declarativo, e dar menos trabalho, quando uso ifs preciso armazenar as condicionais em variáveis me cansa, para ficar mais expresso e acaba sendo bem chato pensar em bons nomes
Porque a otimização de Java é uma porcaria, não atoa toda aplicação que precisa de velocidade e confiabilidade é escrita em C/C++ e alguns casos em Assembly
Basicamente a maioria das linguagens populares já deve otimizar 99% próximo a perfeição, com exceção de códigos muito complexos ou de escala quadrática ou acima. Pra gigantesca maioria, pouco importa como você programa, e é muito mais vantajoso ter um código limpo e de fácil leitura do que os 0,1ms de performance a mais.
Eu diria que o switch case fica melhor considerando nomes reais de variaveis com 10 caracteres em media, fica ruim de ler no meio de varios else if aninhado...Muito massa o video!
Entao por via das dúvidas eu acho que se puder usar o switch é o melhor caso na maioria das vezes pois no final você dependerá de como o compilador vai passar pro código da máquina. Hashtables são vida
Excelente vídeo. Fiz um comentário parecido há 10 dias sobre esse tem em um de seus vídeos falando sobre else. Sobre usar else if's é mais eficiente que somente if's. Usar arrays para armazenar funções é bem interessante. Quando tinha trabalhos na facul como criar jogos, eu criava um array chamado teclado e atribuia as funções que cada tecla nele, usando ponteiro de função.
É uma boa abordagem, mapear o teclado para um array de funções, me parece elegante e performático, e resolve o problema de conseguir criar configurações de mapeamento de tecla pelo jogador, que inclusive acho algo extremamente usual. Não me imagino jogando Counter Strike sem as "binds" que já acostumei, por exemplo.
O Switch realmente é melhor, até que no codigo seja necessario fazer uma comparação de maior que ou menor que, que vai ser quando o codigo terá de ser refatorado praticamente inteiro para um if-else encadeado OU um if "especial" dentro do default.
Mano, onde eu acho um "manual" com as otimizações que eu posso fazer nos meus códigos em python? Tava querendo participar da OBI esse ano e essa parte de código nao otimizado me pegou muito ano passado...
Eu escolheria o que gastaria menos bytes, exemplo para programação de um código para o arduino que tem pouca memória de armazenamento para o sketch compilado, uma boa ideia seria testar a compilação dos dois códigos afim de descobrir qual deles possue menos bytes, gostei do vídeo foi muito interessante
Sigo um pensamento para Switch case e if encadenado. Ha basante tempo eu vi que nao era muito diferente de performance, mas ai entra a legibilidade. Para ifs com mais de 2 condiçoes eu ja coloco um switch. Quando é só 2, eu fico no IF. Isso acabou sendo adotado pela equipe e fica mais facil de bater o olho e sabe o que esperar do codigo.
Não, porque na maioria das linguagens o switch não cobre todos os casos que o if cobre. Switch não checa se uma variável é maior que outra, por exemplo, nem resolve expressões
Aqui na empresa e na minha vida de programador eu bani (usando ferramentas de qualidade de código) o uso de "switch/case" que exige "break", como em JS, TS e Java. Pelo menos pra mim a existência desse "break" é uma armadilha que pode causar sérios problemas, principalmente quando tem programadores inexperientes na equipe. Linguagens como Go, Ruby, Rust e até o Delphi tem uma excelente abordagem de como deve ser uma cláusula "switch/case" decente, principalmente por permitir usar "break" para sair de um laço sem muitos malabarismos complicados de explicar a um iniciante. Obs1: Eu sei que é possível usar as ferramentas de qualidade código para exigir o "break" ao invés de bani-lo, mas "switch/case" com "break" é feio e prefiro banir; Obs2: Sempre vou preferir código fácil de ler do que insignificativamente performático para o contexto, portanto, entre "if" e "switch/case" com "break" vou preferir um monte de "if" (claro que se for possível vou preferir usar OOP com nenhum ou quase nenhum "if"); Obs3: Aceito tentativas de me convencer a usar uma p0rc*ria dessas com "break";
Eu uso break em .NET, pois uso muitos switchs e eles implementam por padrão o break em todos os cases. Na sua visão, teria algum problema em continuar usando?
@@imperiaonlinebr Costumo dizer o seguinte, não é porque existe que deve ser utilizado, não é porque dá pra fazer que deve ser feito. Na minha visão, "switch/case" que obriga usar "break" nos blocos para não continuar avaliando as condições seguintes é no mínimo um anti-pattern que deve ser evitado a todo custo; pra mim é um erro de implementação que já deveria ter sido corrigido há muito tempo e jamais deveria ser o comportamento padrão. Em Java até uns tempos atrás (não sei como anda hoje em dia), se você colocasse um "switch/case" dentro de um laço de repetição e um bloco/condição com "break" fosse executado, o "break" do "switch/case" interrompia a execução do laço como se o "break" fosse do laço, e pra resolver essa anomalia tinha soluções ainda piores em termos de legibilidade. No fim das contas passamos mais tempo fazendo manutenção no código e sempre tem novatos pra ajudar na manutenção, e por um descuido esquecer de colocar o "break" pode causar falhas muito graves, por isso prefiro banir o uso de "switch/case" do que ter que ficar explicando ou ensinando sobre esse comportamento ridículo do "switch/case". O "if" é muito mais intuitivo e dispensa explicações. Um outro recurso de linguagens de programação que também deixo banido é a cláusula "with", que a meu ver é um verdadeiro Cavalo de Troia que é usado para supostamente facilitar o acesso aos atributos de classes e outros objetos, o problema neste caso é que posteriormente dificulta demais uma depuração do código e também dificulta fazer pesquisas estruturais.
Tendo a usar mt mais switch por causa da legibilidade. A diferença em velocidade geralmente é negligenciável (tanto pra mais quanto pra menos), só que deixa o código mais gostoso de ler. falando em gostoso, ta aqui uma receita de brigadeiro de microondas: 1 lata de leite condensado 4 colheres (sopa) de chocolate em pó ou achocolatado 1 colher (sopa) de margarina chocolate granulado ou granulado colorido >:>:>:>:>:>>::>>::>:>:>:>:>:>::>:>>:>:>:>:> Em um recipiente próprio para microondas, de preferência redondo e de borda alta, misture todos os ingredientes. Leve ao microondas por 6 minutos em potência alta ou na tecla brigadeiro do próprio microondas. Mexendo a mistura na metade do tempo. Depois de pronto, retire do forno e mexa até ficar uma massa lisa e brilhante. Leve à geladeira para esfriar, depois enrole os docinhos, passe no granulado e coloque nas forminhas.
switch é mais legível, pórem tenque ficar escrevendo break no fim, e não da pra ter um desvio do fluxo, por exemplo: se no switch der o case 3, mas precisar validar outra condição junto dessa já vai ser inutil, ou tbm... se precisar fazer um retorno se o case 3 não for valido, ai vc deve pensar é só por no "default:", mas e se antes de cair no default ele caia no case 4? inutil tbm, por isso nunca usei switch
Cara, na minha visão, se o seu código tem tantas condições hardcoded ao ponto que usar um Switch no lugar do If..Else faça MUITA diferença na performance, você está fazendo algo errado kkkkkkk
Наука
![Sean Rii, Karyon, Sharzkii - Taungule [My Love] (Official Music Video)](http://i.ytimg.com/vi/eJoMuypbSzQ/mqdefault.jpg)
Eu trabalho com C embarcado pra DSP de controle de motor. A otimização do compilador no meu caro praticamente dobra o desempenho do código. Eu rodo um algoritmo de controle que sem otimização consegue rodas só em 12KHz, quando liga as otimizações globais ele chega a rodar em 25 KHz.
Fora isso tem que tomar cuidado com a otimização do embarcado que ele pode mudar as funções de ponto flutuante e fazer uns arredondamentos e simplificações em interrupções que podem dar problema.
Por isso é importante pelo menos ter uma ideia do que acontece por baixo dos panos!
Cuidado carinha, não fala de embarcado aqui se não a galera vem surtar falando que é a mesma coisa que programar pra PC que otimização não faz diferença e tal que os embarcados hoje são os processadores mais eficientes e potentes já criados pela humanidade.
🤣😂🤣😂
Eu respeito demais quem trabalha com embarcados.
Tropa do embarcado
Excelente, trabalho com TA ou também conhecido como CLP, também as vezes enchemos de coisas e o ciclo de Scan sobe lá na galáxia e fica inviável o controle do processo. Por isso que quando criamos e alteramos algum software já pensamos na otimização.
Você é a ÚNICA pessoa que eu vi que explica o porquê do switch ser mais rápido. Eu realmente não achei explicação boa e acurada igual ao seu video. Muito bom
explicou ele deu um conceito teórico e depois mostrou que eo codigo assemble gerado é o mesmo, entendi que no final da no mesmo
Monstro demais! Claro e objetivo nas explicações.
então, no fim "depende" é a melhor resposta como sempre,
mas...depende.
papagaio aprende a dizer "depende" e vira dev senior
@@kkkippy o valor verdade dessa sua proposição depende
...
🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣
Vc sabia que toda resposta "depende" também depende?
a melhor resposta é: se quiser sim mano
@@kkkippy olha qm eu achei kkkkkkkkk
interessante! pior que já teve umas 2x que eu fiz esse teste em projetos pessoas e para mim o swtich/case apresentou uma performance levemente melhor (javascript)
Já ia tirar essa dúvida, se em JS para web teria mudança na performance e se valeria a pena implementar
Po, se tu quer perfomance provavelmente JavaScript não é a melhor opção.
@@thenub8532 Sim, mas quando se trabalha com React no Frontend, não tem outra opção né. É procurar alternativas de melhorar o que se tem
Ih, javascript é a maior incognita da face da terra.
TUDO depende.
Tu usou console.log? Já não é a performace real, qual interpretador foi usado? Se for navegador cada um interpreta do seu jeito, se for node cada versão vem embarcada com um interpretador diferente.
Se for em TypeScript ao inves de Javascript a performace vai piorar umas 500x pq o transpilador vai fazer um MONTE de merda no codigo JS e por ai vai...
@@thenub8532 Mas isso não tem nada a ver mano.
Só porque javascript não é tão performático não significa que ele tenha que uso isso como desculpa pra fazer o código de qualquer jeito kkkkk
Acabou de ganhar um sininho. Muito interessante o assunto e o jeito que voce abordou. Parabéns!!!
Entramos numa discussão sobre performace entre Switch e IF ELSE, e terminamos com uma discussão em aberto entre o que é mais legível: Switch ou IF ELSE (e sei que tem gente que odeia um ou outro)
nunca gostei de if else... preferia criar if's soltos... com o tempo deduzi q if else era mais performático (pq no caso de if's soltos, a máquina verifica tudo)... nn gosto de switch pq axo xato de editar (em c#)... enfim...
Muito bom!
Sensacional o conteúdo!
Ótimo conteúdo amigo!
Interessante. Switch case deve ser usado quando se tem muitas opções de entrada, se usar if else nessas situações o compilador leva muito tempo pra executar o programa. Ja o if else se usa nas situações onde se tem poucas opções ou situações booleanos( verdadeiro ou falso)
Seus conteúdos são foda mano, tras videos sobre SQL
Em resumo escreva como vc preferir, só lembre-se de usar -o2 quando for compilar
Caramba gostei da sua forma de explicar parabéns sua forma de explicar é única
Se me lembro direito, ARM aloca a tabela de saltos no bloco da função e tem instrução que indexa a tabela com um offset e faz salto no mesmo ciclo utilizando o program counter como registrador de uso geral , então geralmente switch case é mais rápido e ocupa menos espaços em arquitetura ARM cortex-m. O Else If em ARM sempre faz uma comparação e salta depois de verificar o registrador de status, se tiver sorte você vai ter um salto em 2 ciclos, mas se tiver azar e o branch predctior falhou você leva um flush e perde os três estágio de pipeline.
Mas com RISC-V e outros processadores super escalares as coisas mudam e geralmente não tem diferença entre os dois, porque mesmo com otimização de compilação ultra mega cosmic vegana pica, tudo depende do humor do escalonador no ciclo do salto.
Em x86_64 é ainda pior, já que geralmente esses processadores tem de 11 a 22 estágios de pipelines que podem executar instruções fora de ordem, o branch predctior pode fazer o salto três ciclos antes da comparação do Else If ou um Else If no final do bloco pode ser processado no começo porque o processador quis e ele quer que se dane a sua opinião porque ele não liga para você 😐
Quando acordo vou ver se esse home postou algum conhecimento para um mero estudande de desenvolvimento. Muito bom, porém, estranho eu fazer isso...😅
Conteúdo top, inscrito++
Muito bom 👏🏾
sensacional!
Ótimo vídeo!
Vídeo e conteúdo de grande qualidade
É muito difícil o problema de performance ser o IF, além que se tem uma caralhada de if, é melhor usar polimorfismo ou um map com valor uma função anônima
pessoalmente amo switch por que fica mt clean, sempre que o código involve interface de comunicação com usuário aparece bastante if else, switch sempre salva muitoo
Switch pode não ser mais rápido mas fica bem mais clean que um monte de If/else/else if
Brabo demais
Cara, onde vc adquire esses conhecimentos tão técnicos?
Parabéns pelo vídeo, eu confesso que em casos assim eu não ligo pra performance, pq se não eu ia começar a mexer com bitwise, gosto mais de usar o swirch por parecer mais declarativo, e dar menos trabalho, quando uso ifs preciso armazenar as condicionais em variáveis me cansa, para ficar mais expresso e acaba sendo bem chato pensar em bons nomes
Interessante demais, fiz o mesmo teste no Java e mesmo nas versões mais recente só usa o table-switch no switch case.
Porque a otimização de Java é uma porcaria, não atoa toda aplicação que precisa de velocidade e confiabilidade é escrita em C/C++ e alguns casos em Assembly
Caraca, não tinha noção do quão o compilador podia otimizar o código. Muito massa
Basicamente a maioria das linguagens populares já deve otimizar 99% próximo a perfeição, com exceção de códigos muito complexos ou de escala quadrática ou acima.
Pra gigantesca maioria, pouco importa como você programa, e é muito mais vantajoso ter um código limpo e de fácil leitura do que os 0,1ms de performance a mais.
Eu costumo usar mais o if principalmente pra fazer comparacoes
Eu diria que o switch case fica melhor considerando nomes reais de variaveis com 10 caracteres em media, fica ruim de ler no meio de varios else if aninhado...Muito massa o video!
Entao por via das dúvidas eu acho que se puder usar o switch é o melhor caso na maioria das vezes pois no final você dependerá de como o compilador vai passar pro código da máquina. Hashtables são vida
Se eu tivesse um array de respostas ou chamadas de funções seria gerado o mesmo assembly??
Excelente vídeo. Fiz um comentário parecido há 10 dias sobre esse tem em um de seus vídeos falando sobre else. Sobre usar else if's é mais eficiente que somente if's.
Usar arrays para armazenar funções é bem interessante. Quando tinha trabalhos na facul como criar jogos, eu criava um array chamado teclado e atribuia as funções que cada tecla nele, usando ponteiro de função.
É uma boa abordagem, mapear o teclado para um array de funções, me parece elegante e performático, e resolve o problema de conseguir criar configurações de mapeamento de tecla pelo jogador, que inclusive acho algo extremamente usual.
Não me imagino jogando Counter Strike sem as "binds" que já acostumei, por exemplo.
que video bom kkkk
Acham que faz alguma diferença se for usado um dicionário e a função .get no caso do Python pra agilizar/otimizar o código?
O Switch realmente é melhor, até que no codigo seja necessario fazer uma comparação de maior que ou menor que, que vai ser quando o codigo terá de ser refatorado praticamente inteiro para um if-else encadeado OU um if "especial" dentro do default.
Mano, onde eu acho um "manual" com as otimizações que eu posso fazer nos meus códigos em python? Tava querendo participar da OBI esse ano e essa parte de código nao otimizado me pegou muito ano passado...
Eu escolheria o que gastaria menos bytes, exemplo para programação de um código para o arduino que tem pouca memória de armazenamento para o sketch compilado, uma boa ideia seria testar a compilação dos dois códigos afim de descobrir qual deles possue menos bytes, gostei do vídeo foi muito interessante
no caso de embarcados essa mentalidade é mt importante, pra aplicações web e outras acho que não é tão necessário
Vídeo top, vc não encontra uma explicação em cursos e faculdade, muito bom ..
Gosto do ifelse porque posso usar mais padrões, como yoda conditions e etc...
Eu uso select case ou swith no caso para ficar mais bonito okk
04:46 - "if else é um pouquinho mais barato que o cálculo de jump table". Poderia dizer o porquê?
Sigo um pensamento para Switch case e if encadenado. Ha basante tempo eu vi que nao era muito diferente de performance, mas ai entra a legibilidade. Para ifs com mais de 2 condiçoes eu ja coloco um switch. Quando é só 2, eu fico no IF. Isso acabou sendo adotado pela equipe e fica mais facil de bater o olho e sabe o que esperar do codigo.
qual e o nome do software de desenho ?
Augusto, qual o quadro que tu usa pra fazer as análises?
Excalidraw
No fim switch ou esse depende mais de legibilidade
6:20 Claro que gera o memo codigo. Isso é c, a melhor e mais optimisada linguagem do mundo. Respeito
Em termos de performance, nao necessariamente segurança
Resumindo: o compilador é mais inteligente do que você.
Entre if else e switch case eu prefiro dict map🍷🗿
switch case é mais rapido que uma IA
Se "if else" fosse de tão baixa performance em relação ao "switch", o "if else" já seria extinto.
Não, porque na maioria das linguagens o switch não cobre todos os casos que o if cobre. Switch não checa se uma variável é maior que outra, por exemplo, nem resolve expressões
Pra que serve o compilador?
Prefiro um polimorfismo
me perdoe por qualquer dia ter feito uma calculadora e dito que estava programando
Aqui na empresa e na minha vida de programador eu bani (usando ferramentas de qualidade de código) o uso de "switch/case" que exige "break", como em JS, TS e Java.
Pelo menos pra mim a existência desse "break" é uma armadilha que pode causar sérios problemas, principalmente quando tem programadores inexperientes na equipe. Linguagens como Go, Ruby, Rust e até o Delphi tem uma excelente abordagem de como deve ser uma cláusula "switch/case" decente, principalmente por permitir usar "break" para sair de um laço sem muitos malabarismos complicados de explicar a um iniciante.
Obs1: Eu sei que é possível usar as ferramentas de qualidade código para exigir o "break" ao invés de bani-lo, mas "switch/case" com "break" é feio e prefiro banir;
Obs2: Sempre vou preferir código fácil de ler do que insignificativamente performático para o contexto, portanto, entre "if" e "switch/case" com "break" vou preferir um monte de "if" (claro que se for possível vou preferir usar OOP com nenhum ou quase nenhum "if");
Obs3: Aceito tentativas de me convencer a usar uma p0rc*ria dessas com "break";
Eu uso break em .NET, pois uso muitos switchs e eles implementam por padrão o break em todos os cases. Na sua visão, teria algum problema em continuar usando?
@@imperiaonlinebr Costumo dizer o seguinte, não é porque existe que deve ser utilizado, não é porque dá pra fazer que deve ser feito. Na minha visão, "switch/case" que obriga usar "break" nos blocos para não continuar avaliando as condições seguintes é no mínimo um anti-pattern que deve ser evitado a todo custo; pra mim é um erro de implementação que já deveria ter sido corrigido há muito tempo e jamais deveria ser o comportamento padrão. Em Java até uns tempos atrás (não sei como anda hoje em dia), se você colocasse um "switch/case" dentro de um laço de repetição e um bloco/condição com "break" fosse executado, o "break" do "switch/case" interrompia a execução do laço como se o "break" fosse do laço, e pra resolver essa anomalia tinha soluções ainda piores em termos de legibilidade.
No fim das contas passamos mais tempo fazendo manutenção no código e sempre tem novatos pra ajudar na manutenção, e por um descuido esquecer de colocar o "break" pode causar falhas muito graves, por isso prefiro banir o uso de "switch/case" do que ter que ficar explicando ou ensinando sobre esse comportamento ridículo do "switch/case". O "if" é muito mais intuitivo e dispensa explicações.
Um outro recurso de linguagens de programação que também deixo banido é a cláusula "with", que a meu ver é um verdadeiro Cavalo de Troia que é usado para supostamente facilitar o acesso aos atributos de classes e outros objetos, o problema neste caso é que posteriormente dificulta demais uma depuração do código e também dificulta fazer pesquisas estruturais.
Switch: maquina de estados mais legível
If else: logica nao cíclica.
Fodase o resto
Tendo a usar mt mais switch por causa da legibilidade.
A diferença em velocidade geralmente é negligenciável (tanto pra mais quanto pra menos), só que deixa o código mais gostoso de ler.
falando em gostoso, ta aqui uma receita de brigadeiro de microondas:
1 lata de leite condensado
4 colheres (sopa) de chocolate em pó ou achocolatado
1 colher (sopa) de margarina
chocolate granulado ou granulado colorido
>:>:>:>:>:>>::>>::>:>:>:>:>:>::>:>>:>:>:>:>
Em um recipiente próprio para microondas, de preferência redondo e de borda alta, misture todos os ingredientes.
Leve ao microondas por 6 minutos em potência alta ou na tecla brigadeiro do próprio microondas. Mexendo a mistura na metade do tempo.
Depois de pronto, retire do forno e mexa até ficar uma massa lisa e brilhante.
Leve à geladeira para esfriar, depois enrole os docinhos, passe no granulado e coloque nas forminhas.
switch é mais legível, pórem tenque ficar escrevendo break no fim, e não da pra ter um desvio do fluxo, por exemplo: se no switch der o case 3, mas precisar validar outra condição junto dessa já vai ser inutil, ou tbm... se precisar fazer um retorno se o case 3 não for valido, ai vc deve pensar é só por no "default:", mas e se antes de cair no default ele caia no case 4? inutil tbm, por isso nunca usei switch
Cara, na minha visão, se o seu código tem tantas condições hardcoded ao ponto que usar um Switch no lugar do If..Else faça MUITA diferença na performance, você está fazendo algo errado kkkkkkk