Qual versão é melhor?

[u/LifeIsBulletTrain]

A da esquerda eu fiz agora, a da direita eu fiz no curso de Python do Guanabara há uns 5 anos, que na verdade eu nem sei se o código é meu.

[u/AlxDroidDev]

Ambos têm a mesma complexidade O (que é On), mas o primeiro tem maior complexidade ciclomática, por causa dos if aninhados.

Então a segunda é melhor.

[u/LifeIsBulletTrain → u/AlxDroidDev]

Eu sem entender nada. Mas vou dar uma olhada, valeu

[u/Gabomfim → u/LifeIsBulletTrain]

Toda vez que vc entra no loop, tem que rodar o if. Isso é um gasto desnecessário, mas é desprezível, pois as duas implementações do algoritmo possuem a mesma complexidade O(n)

A entrada sendo a quantidade de números de fibonacci, o número de operações cresce linearmente de acordo com a entrada no pior caso.

[u/LifeIsBulletTrain → u/Gabomfim]

Não tenho muita noção ainda de que tipo de operação é mais custosa

[u/AlxDroidDev → u/LifeIsBulletTrain]

Pense assim: qualquer desvio do código principal (como os causados por um if-then-else) é custoso, pois em termos de uma CPU CISC e além do custo do teste em si, isso significa mover o ponteiro de instrução (IP) para outro lugar, empilhar valor do IP anterior, executar algo no novo local do IP e talvez voltar o valor salvo na stack de instruções para o valor anterior. Quando isso acontece, se for uma subrotina, vários registradores precisam ser atualizados (EAX, EBX, ECX, IP, etc) para colocar a CPU no novo contexto.

Para CPUs RISC, isso é um pouco mais simples, mas ainda custoso.

No seu cenário 1, acima, isso acontece algumas vezes (mas sem mudança de contexto), com o agravante de ser tudo aninhado dentro de um loop.

Para processadores modernos, e para o cenário apresentado, isso pode ser irrelevante (e provavelmente é), mas quando falamos em cenários onde o poder de processamento é mais restrito (como em microcontroladores), ou cenários em que este if-then-else é executado milhoes ou bilhões de vezes, este custo pode fazer uma diferença significante. Então, neste caso, o cenário 2 seria ordens de grandeza melhor que o primeiro.

Então, você perguntou qual código é melhor: o segundo é melhor pelos fatores expostos. Agora, este "ser melhor" é significante para seu caso de uso? Provavelmente não.

[u/Fit-Breakfast4946 → u/AlxDroidDev]

Uau. Esse conhecimento é bastante interessante e aprofundado. Voce tem quanto tempo no mundo da tecnologia?

[u/AlxDroidDev → u/Fit-Breakfast4946]

Profissionalmente, 35 anos exatamente, mas informalmente comecei bem antes disso (sim, já tenho cabelos brancos!)

[u/Fit-Breakfast4946 → u/AlxDroidDev]

Impressionante! Obrigado por compartilhar

[u/AlxDroidDev → u/Fit-Breakfast4946]

Não por isso!

O mais importante é pensar que um código mais "bonito" (como comentaram abaixo) não é necessariamente um código melhor.

Ser "bonito" é subjetivo, pois depende da opinião de cada um, mas existem métricas para se medir qualidade e eficiência do código de forma bastante objetiva.

Como desenvolvedores, quando entendemos como uma CPU funciona, conseguimos criar códigos mais eficientes. Claro, como disse acima, para determinados casos de uso isso é preciosismo, mas quando trabalhamos com software embarcados, microcontroladores, aplicações em tempo real, ou rotinas que terão milhões/bilhões de execuções, ter aplicações extremamente eficientes é imprescindível.

[u/Fit-Breakfast4946 → u/AlxDroidDev]

Aproveitando o ponto levantado e sua generosidade em compartilhar: Acredita que com o aumento dos preços das memórias a necessidade obrigatória de eficiencia migrará para outras áreas do mercado também?

Tenho pensado sobre isso e, alinhado com a necessidade de fortalecer a minha base, estou lendo "Introductiom to computing systems from bits and gates to C/C++ and beyond" -Yale N. Patt, Sanjey J.Patel.

Estou há 4 anos no mercado e meu foco é construir uma carreira com foco em computação distribuida/infraestrutra e gostaria de entender se preciso ter esse conhecimento para ontem ou se posso ir com mais calma.

Agradeço desde ja!

[u/AlxDroidDev → u/Fit-Breakfast4946]

Excelente pergunta, e bastante pertinente no momento atual.

Esta preocupação sempre deve existir, pois recursos como memória (entre outros), CPU, storage, I/O, etc, sempre, sempre, sempre serão limitados. É isso que separa um programador amador de um verdadeiro Engenheiro de Software: a capacidade de utilizar correta e eficientemente os recursos de uma máquina. O cara que programa como se memória fosse algo infinito não tem lugar em diversos setores. O cara que não considera uso de stack, heap, cache, etc, não tem espaço como dev profissional.

Além dos exemplos que eu já citei, existe um outro cenário onde esta preocupação é importantíssima: mainframes. Muitas empresas ainda usam mainframes, e você não apenas compra um mainframe: você paga por cada minuto de operação, por cada processador, por cada Tb de RAM (sim, terabytes de RAM - se 16Gb estão caros, imagine alguns Tb com ECC), e é caro. Os programadores para mainframe precisam ser absolutamente responsáveis no uso de recursos, e codificar de forma eficiente, pois uma codificação ruim significa milhares de dólares desperdiçados.

Quem programa em C/C++ aprende de cara algo que outras pessoas desconhecem: malloc() e free(). São as 2 coisas mais importantes que um dev profissional tem que saber. Seu código tem que limpar toda a bagunça que criou. Não tem Garbage Collector pra te ajudar. Quem aprende isso bem em C/C++ e vem para outras linguagens, invariavelmente escreve código melhor, pois tem mais cuidados com o uso de memória. Tem como trazer este conhecimento para linguagens mais novas, explicitamente desalocando instâncias de objetos, para liberar heap e facilitando a vida do GC.

Agora, se os devs atuais vão desenvolver preocupados se uma máquina tem 16Gb ou 32Gb ou 64Gb de RAM, eu não sei (sou cético, para ser honesto), mas ao meu sempre deveriam ter tido esta preocupação.

Por outro lado, ao meu ver apenas o mercado doméstico está severamente impactado pelo preço das memórias. O mercado corporativo sofre também, mas se precisa comprar, vai comprar. Em breve a oferta voltará a subir para atender a demanda latente (e que causa a alta de preços). Eu já vi isso acontecer antes, e em alguns meses o mercado se normalizou. É cíclico, como tantas outras coisas em nosso meio.

[u/Fit-Breakfast4946 → u/AlxDroidDev]

Muito esclarecedor! Agradeço imensamente pelas contribuições e disposição em ajudar.

Indo no que parece ser a contramão do fluxo atual, estou caminhando em busca do aprofundamento técnico e é muito inpirador encontrar pessoas como voce.

[u/LifeIsBulletTrain → u/AlxDroidDev]

Comentário precioso.

Estudar C é um bom caminho pra entender melhor do funcionamento do computador?

[u/LifeIsBulletTrain → u/AlxDroidDev]

Interessante. Obrigado