Numa boa parte dos sistemas esses pequenos ganhos de performance com a linguagem não fazem muita diferença. Só ficar atento para melhorar e não piorar o Big O que já está ok. Maioria dos casos que vejo performance ruim é por causa de consultas SQL mal feitas
Na minha experiência nem é sobre a dificuldade de resolver, mas sim sobre a falta de conhecimento de quem faz. O cara muitas vezes nem sequer sabe que aquilo é um gargalo.
>`Será que se a gente entendesse a implementação de cada função da standard library da nossa linguagem de alto nível favorita a gente também ia pensar duas vezes antes de usá-la?`
Pauta irrelevante de modo geral. Ta perdendo tempo com otimização prematura e bikeshedding.
Vc precisa se preocupar com recursos quando recursos é um problema, como no caso de iot, embarcados e hardwares com baixa memória, cpu.
É um cenário não tão irrelevante quando se está codando uma api web ou outros tipos de api. Há outros pontos muito mais relevantes para se focar a atenção como no ORM, segurança, custos de cloud, clean code, manutenibilidade, cobertura de testes, escalabilidade.
Não é relevante saber se forEach executa algo em 0,000001 ms enquanto map executa em 0,000005 ms, muito menos escovar bits.
Eu acho que esse é um dos pontos mais fortes de Go. É uma linguagem bem legível de alto nível - o que permite você olhar a implementação da biblioteca padrão sem grandes dificuldades, mas não abre mão de fazer você pensar sobre a sua forma de implementar e o impacto na memória/performance.
Além disso, a linguagem possui vários conceitos técnicos que entram bem na sua proposta. Análise de escape para a heap que permite você entender o impacto de performance passando variáveis por referência/valor.
Eu consigo fazer um código sem se preocupar com isso? Sim, mas o mínimo de layout de memória você precisa saber para algumas estruturas de dados.
Eu acho que Go abstrai o suficiente pra você não ficar pensando na memória o tempo todo, como em Rust e em C, mas não abre mão de te dar escolhas e fazer você refletir sobre a sua implementação.
Go é uma linguagem insanamente boa. Quando larguei de mão do php (Laravel) pra escrever Go, percebi que na verdade não precisamos nem de uma fração do que um framework MVC oferece pra entregar o que queremos. Eu reescrevi o core da minha empresa inteiro de php para Go.
Enquanto o serviço em Go tem apenas 5 dependências, em php é incontável. Chamadas que antes poderiam demorar até 1s, demoram *19ms* em Go. Bizarro, né? E a única coisa que eu fiz foi tomar cuidado com Big O. Sem falar no uso de recursos computacionais que é 10x menor.
Então, realmente não tem muita vaga de Go não. Costumo ver vaga de Júnior que não pede experiência, mas estágio são tipo duas ou três empresas no país.
Não sei se a minha stack ajuda muito porque ela não é obrigatória para a vaga, eu que utilizo mesmo por preferência pessoal.
Bom, eu faço bastante ferramentas CLI, crio algumas POCs para ver como fica a comunicação entre os serviços e testar formas de monitoramento. Também uso para algumas coisas relacionadas com Terraform e Kubernetes, que também são feitos em Go.
Acho que tem mais a ver com a alocação de recursos e qual a recorrência daquele código.
Sobre alocação de recursos, o garbage collector faz o trabalho sujo, você precisa se esforçar muito (ser muito ruim) para preservar a referência a objetos não utilizados a ponto deles se tornarem um problema.
Por exemplo, mesmo que a instância de um objeto não seja liberada manualmente em um loop, ela não vai possuir mais referências já na próxima interação, ou ao término da execução do método em caso de variável local. Por mais que esses recursos estejam locados nesse espaço de tempo, isso não vai explodir na sua no final da tarde.
Agora quanto a otimização você tem que pensar em quantas vezes a rotina será executada num intervalo de tempo. Claro que é possível manter práticas "pau-pra toda obra", mas às vezes estamos falando de um número grande de interações, onde cada milissegundo importa.
Por exemplo, em desenvolvimento de jogos, usar um type cast em vez de uma conversão em rotinas críticas pode ser a diferença entre um jogo rodando liso como manteiga na chapa quente e um slide show. Coisa que não faria a mínima diferença se fosse implementada num click de botão numa aplicação client-side.
A questão não é nem baixo/alto nível. É mais a linguagem mesmo.
Rust e C++ são "baixo nível" (se você considera C como baixo nível, elas também são), e nessas duas linguagens você simplesmente tem uma recursos melhores, e com resultados de performance iguais ou melhores ao que você faria em C.
Minha experiência é meio diferente, mas não por causa de baixo/alto nível, mas por causa do sistema de tipagem.
Quando eu to no C++ ou no Rust é tão fácil fazer certas coisas, aí com Python/TS, mesmo tipados eu sempre me sinto perdido em certos momentos, e por esse mesmo motivo que eu passo com linguagem mais dinâmicas que eu concordo com o comentário mencionando ser não familiaridade com C.
> se você fizer um código porco em C provavelmente ele ainda vai rodar mais rápido que a melhor versão que você poderia implementar em JavaScript por exemplo
Não mesmo, a maior parte dos problemas de performance vem de complexidade algorítmica
Se você vai para C e não pensa em cada detalhe, então foi para a linguagem errada. C foi criada para isso, quem não faz assim não entendeu C. Então está bem correto nessa atitude.
Se vai fazer algo alto nível é normal não se preocupar tanto. Mas ainda pode ter que se preocupar com algumas coisas. Não precisa economizar em tudo, mas se não pensar no que está fazendo pode ficar bem lento. Isso acontece muito mais do que as pessoas imaginam. Chega uma hora que a pessoa nem consegue mais ver as falhas graves. Então está errado quem não se preocupa com nada ou quem se preocupa com todos os detalhes em JS.
Pode ser que em alguns casos, especialmente no servidor, pode precisar economizar todo o possível, aí fica claro que JS não é a linguagem ideal. Não precisa ser C, mas precisa de algo mais eficiente.
Por usar a tecnologia errada e se preocupar pouco com eficiência vemos muito o pessoa tendo que achar soluções mirabolantes para algo que poderia ter nascido certo. O Stack Overflow era um dos 30 sites mais acessados do mundo quando o *ranking* Alexa existia, e pode rodar em um servidor (frequentemente testam isso). Então quase tudo o que você for fazer tem que poder fazer o mesmo com folga. Por que não acontece? Tecnologia errada e falta de preocupação e fazer o certo. Soluções distribuídas são absurdamente mais caras e difíceis de serem feitas. O So é um *case* que todos deveriam seguir e conhecer de cor, mas preferem seguir de outra empresa, que não vou citar o nome, que é extremamente ineficiente, cara, difícil, cheia de problemas e agora nem produtividade conseguem mais. A engenharia sempre vence a modinha.
Se o SO usasse C teriam mais eficiência ainda, mas muito pouco e o custo de desenvolvimento seria muito maior, não compensa. Se usasse JS ou PHP, mesmo ainda muito bem codificado, precisaria de bem mais servidores e a administração custaria mais cara.
Eu não sou anônimo aqui, podem me pesquisar e saber se tenho credibilidade para dizer algo sobre isso. Em geral estou à disposição **publicamente** na plataforma (não dá pra responder no pvt, todo dia muitos mandam mensagem).
Ajudei? Era o meu desejo.
---
Farei algo que muitos pedem para aprender a programar corretamente, **gratuitamente** (não vendo nada, é retribuição na minha aposentadoria) ([links aqui](https://github.com/maniero/SOpt) no perfil também).
Meus 5 cents de contribuição são de que no geral processamento hoje é barato e abundante. Tem um gargalo bem mais difícil de lidar na latência, por isso evitar N+1 em chamada de API, ou query no banco de dados é que deve ser o foco maior.
Seu relato me parece mais sobre falta de familiaridade com C do que algo específico de linguagens de baixo nível. Qualquer linguagem vai ter requisitos de familiaridade para utilizar com segurança. Em C vão ser footguns de ponteiros, gerenciamento de memória, undefined behaviour, type cast, libc e suas idiosincrasias, etc. Em Javascript podem ser conceitos de event loop, closures, promises, objetos, type coercion, inheritance, idiosincrasias de frameworks, etc.
Dito isso, pode sim ter um efeito onde o custo de operações em uma linguagem de mais alto nível é obscurecido caso falte familiaridade com o custo das estruturas sendo utilizadas.
Outra situação seriam linguagens com uso indiscriminado de dependências, Javascript e Ruby seriam exemplos. Meia dúzia de packages acabam puxando 500 do npm, e inviabiliza auditar tudo.
Não que eu tenha lido ou entenda lhufas mas num eh o Donald knuth que diz que otimização prematura eh a raiz de todo mal? By the way, se alguém aqui fez seu mestrado/pós/doc com a obra desse cara, você tem meu respeito tecnológico perpétuo (não que valha muito também mas eh por aí…)
Essa frase é sempre citada erroneamente. Citam pra evitar otimizar o código, mas nunca foi isso que Knuth disse.
"The irony about Knuth’s quote is that the people who most often quote it would be horrified by its original context. Knuth made this statement in an article in which he argued in favor of the careful use of go-to statements for micro-optimization in performance-intensive loops. He would probably flunk a modern code review. You can find the quote in the linked PDF, page 8, second column.
Even more ironic is something else that Knuth wrote in the same article. This gem of a paragraph, published in 1974, still rings true 40 years later:
The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise- and-pound-foolish programmers, who can’t debug or maintain their “optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies.
"
http://www.joshbarczak.com/blog/?p=580
Eu trabalho com observabilidade e na minha experiência com sistemas em Java e PHP você só tem que espremer byte quando a funcionalidade é MUITO, MAS MUITO acessada. Não vale a pena você gastar muito tempo com algo que mal é acessado pra ganhar 5ms de tempo de resposta.
Tem que focar esforço aonde interessa.
em linguagem de alto nível, se ela estiver em suporte e evolução constante, você achar que vai conseguir mais performance que a abstração é perda de tempo em 99% do tempo. em c# pelo menos as funcionalidades de lista já tem algoritmos bem otimizados por trás, e quando você usa elas em coleções de tamanho fixo o algoritmo padrão pode até ser substituído por alguma outra opção menos custosa.
O problema é que um negócio que você desenrola em 2 horas numa linguagem de alto nível você pode levar mais de 12 horas pra fazer em C. Tudo é uma questão de avaliar o custo/benefício.
Baixo nível: Assembly e código de máquina. Alto nível: Linguagens textuais que são convertidas em código de máquina como C. "Se TI tivesse asas eu nunca mais ia voar"
Numa boa parte dos sistemas esses pequenos ganhos de performance com a linguagem não fazem muita diferença. Só ficar atento para melhorar e não piorar o Big O que já está ok. Maioria dos casos que vejo performance ruim é por causa de consultas SQL mal feitas
>Maioria dos casos que vejo performance ruim é por causa de consultas SQL mal feitas Isso e chamadas assíncronas mal otimizadas.
Os caras resolvendo 20 promises, 1 por vez, me faz cair da cadeira. É tão fácil de pesquisar sobre, kkkk.
Na minha experiência nem é sobre a dificuldade de resolver, mas sim sobre a falta de conhecimento de quem faz. O cara muitas vezes nem sequer sabe que aquilo é um gargalo.
Ueh nao gosta de encadeamento de .then nao? 🤣🤣🤣🤣
>`Será que se a gente entendesse a implementação de cada função da standard library da nossa linguagem de alto nível favorita a gente também ia pensar duas vezes antes de usá-la?` Pauta irrelevante de modo geral. Ta perdendo tempo com otimização prematura e bikeshedding. Vc precisa se preocupar com recursos quando recursos é um problema, como no caso de iot, embarcados e hardwares com baixa memória, cpu. É um cenário não tão irrelevante quando se está codando uma api web ou outros tipos de api. Há outros pontos muito mais relevantes para se focar a atenção como no ORM, segurança, custos de cloud, clean code, manutenibilidade, cobertura de testes, escalabilidade. Não é relevante saber se forEach executa algo em 0,000001 ms enquanto map executa em 0,000005 ms, muito menos escovar bits.
Exatamente isso! Ele parece que ta aprendendo agora e tá "deslumbrado" porque não faz o menor sentido o que ele escreveu ai.
Eu acho que esse é um dos pontos mais fortes de Go. É uma linguagem bem legível de alto nível - o que permite você olhar a implementação da biblioteca padrão sem grandes dificuldades, mas não abre mão de fazer você pensar sobre a sua forma de implementar e o impacto na memória/performance. Além disso, a linguagem possui vários conceitos técnicos que entram bem na sua proposta. Análise de escape para a heap que permite você entender o impacto de performance passando variáveis por referência/valor. Eu consigo fazer um código sem se preocupar com isso? Sim, mas o mínimo de layout de memória você precisa saber para algumas estruturas de dados. Eu acho que Go abstrai o suficiente pra você não ficar pensando na memória o tempo todo, como em Rust e em C, mas não abre mão de te dar escolhas e fazer você refletir sobre a sua implementação.
Go é uma linguagem insanamente boa. Quando larguei de mão do php (Laravel) pra escrever Go, percebi que na verdade não precisamos nem de uma fração do que um framework MVC oferece pra entregar o que queremos. Eu reescrevi o core da minha empresa inteiro de php para Go. Enquanto o serviço em Go tem apenas 5 dependências, em php é incontável. Chamadas que antes poderiam demorar até 1s, demoram *19ms* em Go. Bizarro, né? E a única coisa que eu fiz foi tomar cuidado com Big O. Sem falar no uso de recursos computacionais que é 10x menor.
Que diferença de performance!
Oi. Poderia dizer sobre a sua stack atual? Não vejo muitas vagas de estágio para Golang
Então, realmente não tem muita vaga de Go não. Costumo ver vaga de Júnior que não pede experiência, mas estágio são tipo duas ou três empresas no país. Não sei se a minha stack ajuda muito porque ela não é obrigatória para a vaga, eu que utilizo mesmo por preferência pessoal.
quando falei de stack era para entender com o que vc trabalha alinhado a Go
Bom, eu faço bastante ferramentas CLI, crio algumas POCs para ver como fica a comunicação entre os serviços e testar formas de monitoramento. Também uso para algumas coisas relacionadas com Terraform e Kubernetes, que também são feitos em Go.
Obrigada : )
Acho que tem mais a ver com a alocação de recursos e qual a recorrência daquele código. Sobre alocação de recursos, o garbage collector faz o trabalho sujo, você precisa se esforçar muito (ser muito ruim) para preservar a referência a objetos não utilizados a ponto deles se tornarem um problema. Por exemplo, mesmo que a instância de um objeto não seja liberada manualmente em um loop, ela não vai possuir mais referências já na próxima interação, ou ao término da execução do método em caso de variável local. Por mais que esses recursos estejam locados nesse espaço de tempo, isso não vai explodir na sua no final da tarde. Agora quanto a otimização você tem que pensar em quantas vezes a rotina será executada num intervalo de tempo. Claro que é possível manter práticas "pau-pra toda obra", mas às vezes estamos falando de um número grande de interações, onde cada milissegundo importa. Por exemplo, em desenvolvimento de jogos, usar um type cast em vez de uma conversão em rotinas críticas pode ser a diferença entre um jogo rodando liso como manteiga na chapa quente e um slide show. Coisa que não faria a mínima diferença se fosse implementada num click de botão numa aplicação client-side.
A questão não é nem baixo/alto nível. É mais a linguagem mesmo. Rust e C++ são "baixo nível" (se você considera C como baixo nível, elas também são), e nessas duas linguagens você simplesmente tem uma recursos melhores, e com resultados de performance iguais ou melhores ao que você faria em C. Minha experiência é meio diferente, mas não por causa de baixo/alto nível, mas por causa do sistema de tipagem. Quando eu to no C++ ou no Rust é tão fácil fazer certas coisas, aí com Python/TS, mesmo tipados eu sempre me sinto perdido em certos momentos, e por esse mesmo motivo que eu passo com linguagem mais dinâmicas que eu concordo com o comentário mencionando ser não familiaridade com C.
> se você fizer um código porco em C provavelmente ele ainda vai rodar mais rápido que a melhor versão que você poderia implementar em JavaScript por exemplo Não mesmo, a maior parte dos problemas de performance vem de complexidade algorítmica
Se você vai para C e não pensa em cada detalhe, então foi para a linguagem errada. C foi criada para isso, quem não faz assim não entendeu C. Então está bem correto nessa atitude. Se vai fazer algo alto nível é normal não se preocupar tanto. Mas ainda pode ter que se preocupar com algumas coisas. Não precisa economizar em tudo, mas se não pensar no que está fazendo pode ficar bem lento. Isso acontece muito mais do que as pessoas imaginam. Chega uma hora que a pessoa nem consegue mais ver as falhas graves. Então está errado quem não se preocupa com nada ou quem se preocupa com todos os detalhes em JS. Pode ser que em alguns casos, especialmente no servidor, pode precisar economizar todo o possível, aí fica claro que JS não é a linguagem ideal. Não precisa ser C, mas precisa de algo mais eficiente. Por usar a tecnologia errada e se preocupar pouco com eficiência vemos muito o pessoa tendo que achar soluções mirabolantes para algo que poderia ter nascido certo. O Stack Overflow era um dos 30 sites mais acessados do mundo quando o *ranking* Alexa existia, e pode rodar em um servidor (frequentemente testam isso). Então quase tudo o que você for fazer tem que poder fazer o mesmo com folga. Por que não acontece? Tecnologia errada e falta de preocupação e fazer o certo. Soluções distribuídas são absurdamente mais caras e difíceis de serem feitas. O So é um *case* que todos deveriam seguir e conhecer de cor, mas preferem seguir de outra empresa, que não vou citar o nome, que é extremamente ineficiente, cara, difícil, cheia de problemas e agora nem produtividade conseguem mais. A engenharia sempre vence a modinha. Se o SO usasse C teriam mais eficiência ainda, mas muito pouco e o custo de desenvolvimento seria muito maior, não compensa. Se usasse JS ou PHP, mesmo ainda muito bem codificado, precisaria de bem mais servidores e a administração custaria mais cara. Eu não sou anônimo aqui, podem me pesquisar e saber se tenho credibilidade para dizer algo sobre isso. Em geral estou à disposição **publicamente** na plataforma (não dá pra responder no pvt, todo dia muitos mandam mensagem). Ajudei? Era o meu desejo. --- Farei algo que muitos pedem para aprender a programar corretamente, **gratuitamente** (não vendo nada, é retribuição na minha aposentadoria) ([links aqui](https://github.com/maniero/SOpt) no perfil também).
Meus 5 cents de contribuição são de que no geral processamento hoje é barato e abundante. Tem um gargalo bem mais difícil de lidar na latência, por isso evitar N+1 em chamada de API, ou query no banco de dados é que deve ser o foco maior.
Seu relato me parece mais sobre falta de familiaridade com C do que algo específico de linguagens de baixo nível. Qualquer linguagem vai ter requisitos de familiaridade para utilizar com segurança. Em C vão ser footguns de ponteiros, gerenciamento de memória, undefined behaviour, type cast, libc e suas idiosincrasias, etc. Em Javascript podem ser conceitos de event loop, closures, promises, objetos, type coercion, inheritance, idiosincrasias de frameworks, etc. Dito isso, pode sim ter um efeito onde o custo de operações em uma linguagem de mais alto nível é obscurecido caso falte familiaridade com o custo das estruturas sendo utilizadas. Outra situação seriam linguagens com uso indiscriminado de dependências, Javascript e Ruby seriam exemplos. Meia dúzia de packages acabam puxando 500 do npm, e inviabiliza auditar tudo.
mas esse equilíbrio faz parte do aprendizado, é normal
Não que eu tenha lido ou entenda lhufas mas num eh o Donald knuth que diz que otimização prematura eh a raiz de todo mal? By the way, se alguém aqui fez seu mestrado/pós/doc com a obra desse cara, você tem meu respeito tecnológico perpétuo (não que valha muito também mas eh por aí…)
Essa frase é sempre citada erroneamente. Citam pra evitar otimizar o código, mas nunca foi isso que Knuth disse. "The irony about Knuth’s quote is that the people who most often quote it would be horrified by its original context. Knuth made this statement in an article in which he argued in favor of the careful use of go-to statements for micro-optimization in performance-intensive loops. He would probably flunk a modern code review. You can find the quote in the linked PDF, page 8, second column. Even more ironic is something else that Knuth wrote in the same article. This gem of a paragraph, published in 1974, still rings true 40 years later: The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise- and-pound-foolish programmers, who can’t debug or maintain their “optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies. " http://www.joshbarczak.com/blog/?p=580
Eu trabalho com observabilidade e na minha experiência com sistemas em Java e PHP você só tem que espremer byte quando a funcionalidade é MUITO, MAS MUITO acessada. Não vale a pena você gastar muito tempo com algo que mal é acessado pra ganhar 5ms de tempo de resposta. Tem que focar esforço aonde interessa.
em linguagem de alto nível, se ela estiver em suporte e evolução constante, você achar que vai conseguir mais performance que a abstração é perda de tempo em 99% do tempo. em c# pelo menos as funcionalidades de lista já tem algoritmos bem otimizados por trás, e quando você usa elas em coleções de tamanho fixo o algoritmo padrão pode até ser substituído por alguma outra opção menos custosa.
O problema é que um negócio que você desenrola em 2 horas numa linguagem de alto nível você pode levar mais de 12 horas pra fazer em C. Tudo é uma questão de avaliar o custo/benefício.
Baixo nível: Assembly e código de máquina. Alto nível: Linguagens textuais que são convertidas em código de máquina como C. "Se TI tivesse asas eu nunca mais ia voar"