Penso que esta captura de tela de uma medida de produtividade realmente existente é suficiente para transmitir o significado do artigo, mas se o leitor estiver interessado em meus pensamentos sobre esse assunto, seja bem-vindo.
Os programadores estão obcecados com a velocidade de execução do programa. Monitoramos a velocidade mesmo onde essa velocidade não é muito importante. Às vezes, contrário ao senso comum e à lógica. Nem mesmo compreendendo completamente o que as palavras "velocidade" ou "desempenho" realmente significam em cada caso. Ainda queremos o hardware mais rápido, o idioma mais rápido e a estrutura mais leve.
De boa vontade, acredito que você, nome de usuário, não é assim. Você é capaz de escrever o benchmark certo, sabe como esse ou aquele tempo de execução funciona, odeia a otimização de velocidade apenas por uma questão de otimização de velocidade e conhece muito sobre hardware. Mas há mais pessoas do parágrafo anterior. Verificado.
Vendo o exemplo na foto acima, engasguei com café pela primeira vez ...
- Como o texto datilografado funciona mais rápido que o javascript e, ao mesmo tempo, consome várias vezes menos memória ?!
- De jeito nenhum!
O texto datilografado não possui seu próprio tempo de execução. Ou seja, você não pode executar texto datilografado em qualquer lugar ou quase em qualquer lugar. Você deve primeiro compilá-lo em javascript, que será executado em tempo de execução, que esse mesmo javascript entende. Nesse caso, o nó v11.3434 agia como um tempo de execução. Por uma feliz coincidência, o exemplo de javascript também é executado no mesmo tempo de execução.
Em vez de comparar idiomas, temos uma micro-competição na programação esportiva.
→ código datilografado
→ código javascript
Acontece que o tempo de execução, o consumo de memória e outras características dependem criticamente de quem escreveu esse código de verificação e como. Obviamente, aqui você pode adotar o argumento que o texto datilografado obriga a escrever "o código certo". Mas ninguém se preocupa em compilar texto datilografado em javascript, e eu também não vi lugares com otimizações.
A propósito, há quanto tempo você vê alguém escrever um código semelhante e passou por uma revisão? Sólido, POO e FP não cheiram aqui. O código é escrito explicitamente em um estilo processual. Porque ele tem uma tarefa diferente. Entenda corretamente, embora o código resolva o problema, ele requer refatoração antes da produção. E não se sabe como a refatoração afetará o desempenho. Mas isso é provavelmente uma escolha difícil.
Nós descobrimos um exemplo. Obviamente, o exemplo é inadequado.
Mas vamos ver como outras linguagens de programação passaram no mesmo teste.
O que você acha, como é certo concluir que o Swift é mais rápido que o Go? Eu acho que isso está errado. Basta ver que duas implementações do Rust (linhas 2 e 6) diferem no tempo em 2 vezes.
E aqui o problema já está parecendo mais sério. Se a comparação de texto datilografado e javascript é vista como uma piada, no caso de outros idiomas, o problema não é tão óbvio. E você começaria a entender qual era o problema se visse esse relatório?
Acontece que o código de referência precisa ser monitorado de perto.
Pergunta: Quando foi a última vez que você viu uma pessoa que estava tentando verificar duas vezes como o código de referência é escrito logo depois que você viu gráficos de desempenho padrão bonitos?
Eu os encontro muito raramente. Eu acho que esses engenheiros são muito poucos.
Por outro lado, diante de meus olhos, existem muitos exemplos em que, com base nesses testes, é feita uma conclusão sobre o desempenho e a leveza da tecnologia. E, a propósito, a opinião pública está sendo formada.
Aqui você pode comparar o desempenho das principais estruturas javascript.
Você ainda confia nos resultados? Eu não
Só isso. Mas há boas notícias. A habilidade do programador ainda é uma grande influência no desempenho do programa.
Conclusão:
Microbenchmarks não mostrará nada a menos que você seja profissional em desempenho para uma plataforma específica. Melhor ainda, você mesmo escreve esses parâmetros levando em conta exatamente seus requisitos e condições, enquanto entende o que está fazendo.
PS:
O post foi escrito como uma resposta às comparações e conclusões precipitadas sobre a produtividade futura. Obviamente, todas as conclusões e argumentos do artigo podem ser fornecidas sem esse exemplo, mas com números e detalhes é mais divertido e claro.