4.4 KiB
Escrevendo e otimizando o código Go
Este documento descreve boas práticas para escrever código Go cde alto desempenho.
Embora existem discussões focadas em tornar os serviços individuais mais rápidos (cache, etc), projetar sistemas distribuídos de alto desempenho está fora do escopo deste trabalho. Já existem bons textos sobre monitoramento e projeto de sistemas distribuídos. Eles englobam um conjunto totalmente diferente de decisões de pesquisa e design.
Todo o conteúdo será licenciado sob o CC-BY-SA.
Este livro está dividido em diferentes seções:
- Dicas básicas para escrever software que não é lento
- Material de nível introdutório (CS 101)
- Dicas para escrever software rápido
- Veja seções específicas sobre como obter o melhor de Go
- Dicas avançadas para escrever software realmente rápido
- Para quando o seu código otimizado não é rápido o suficiente
Podemos resumir estas três seções como:
- "Seja razoável"
- "Seja intencional"
- "Seja perigoso"
Quando e onde otimizar
Estou colocando isso em primeiro lugar porque é realmente o passo mais importante. Nós deveríamos estar fazendo isso?
Toda otimização tem um custo. Geralmente esse custo é expresso em termos de complexidade de código ou carga cognitiva - o código otimizado é raramente mais simples do que a versão sem otimizações.
Mas há outro lado que chamarei de economia da otimização. Como programador, seu tempo é valioso. Há o custo da oportunidade de trabalhar em outras coisas no projeto, por exemplo, quais erros corrigir ou quais funcionalidades adicionar. Otimizar as coisas é divertido, mas nem sempre é a tarefa certa a escolher. O desempenho é um característica (feature), mas entrega e corretude também são.
Escolha a coisa mais importante para trabalhar. Às vezes não é uma otimização da CPU, mas na experiência do usuário. Algo tão simples como adicionar um barra de progresso, ou tornar uma página mais responsiva ao fazer cálculos no plano de fundo depois de renderizar a página.
Às vezes isso será óbvio: um relatório horário que é completado em três horas é provavelmente menos útil do que aquele que é concluído em menos de uma hora.
Só porque algo é fácil de otimizar não significa que vale a pena otimizando. Ignorar os casos mais fáceis é uma estratégia de desenvolvimento válida.
Pense nisso como uma otimização do seu tempo.
Você pode escolher o que otimizar e quando otimizar. Você pode mover o controle deslizante entre "Software rápido" e "Implantação rápida".
As pessoas ouvem e repetem "a otimização prematura é a raiz de todo mal", mas eles perdem o contexto completo da citação.
"Os programadores gastam muito tempo pensando ou se preocupando com a velocidade de partes não-críticas de seus programas. Estas tentativas de conseguir eficiência tem um forte impacto negativo quando a depuração e manutenção são consideradas. Devemos esquecer pequenas eficiências, digamos cerca de 97% do tempo: a otimização prematura é a raiz de todo o mal. Porém nós não devemos deixar passar nossas oportunidades nesses 3% críticos. " -- Knuth (tradução livre)
Adicione: https://www.youtube.com/watch?time_continue=429&v=RT46MpK39rQ * não ignore as otimizações fáceis * mais conhecimento de algoritmos e estruturas de dados torna mais otimizações "fáceis" ou "óbvias"
"Você deve otimizar?" Sim, mas somente se o problema for importante, o programa é realmente muito lento e há alguma expectativa de que pode ser feito mais rápido, mantendo a correção, robustez e clareza ". -- A prática da programação, Kernighan e Pike (tradução livre)
[BitFunnel performance estimation] (http://bitfunnel.org/strangeloop) tem alguns números que tornam esta decisão mais explicita. Imagine uma máquina de busca hipotética que precisa de 30.000 máquinas em vários datacenters. Essas máquinas tem um custo de aproximadamente US$ 1.000 por ano. Se você pode dobrar a velocidade do software, isso pode economizar US$ 15 milhões por ano. Até mesmo um único desenvolvedor gastando um ano inteiro para melhorar o desempenho em apenas 1% vai pagar por si.
Na grande maioria dos casos, o tamanho e a velocidade de um programa não são uma preocupação. A otimização mais fácil é não ter que fazê-la. A segunda otimização mais fácil está apenas comprando hardware mais rápido.
Uma vez que você decidiu mudar seu programa, continue lendo.