59 lines
4.4 KiB
Markdown
59 lines
4.4 KiB
Markdown
# Escrevendo e otimizando o código Go
|
||
|
||
Este documento descreve boas práticas para escrever código Go de alto desempenho.
|
||
|
||
Embora existam discussões focadas em tornar os serviços individuais mais rápidos (cache, etc), projetar sistemas distribuídos de alto desempenho vai além 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:
|
||
|
||
1. Dicas básicas para escrever software que não é lento
|
||
* Material de nível introdutório (CS 101)
|
||
1. Dicas para escrever software rápido
|
||
* Veja seções específicas sobre como obter o melhor do Go
|
||
1. 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:
|
||
|
||
1. "Seja razoável"
|
||
1. "Seja intencional"
|
||
1. "Seja perigoso"
|
||
|
||
## Quando e onde otimizar
|
||
|
||
Estou colocando isso em primeiro lugar porque é realmente o passo mais importante. Você deveria mesmo 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 é uma característica (*feature*), mas entrega e corretude também são.
|
||
|
||
Escolha a coisa mais importante para trabalhar. Às vezes não é em uma otimização da CPU, mas na experiência do usuário. Algo tão simples como adicionar uma 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 de hora em hora que leva três horas para ficar pronto é, 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 ser otimizado. 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ã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 corretude, 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 explícita. 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% irá se pagar.
|
||
|
||
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 decidido que você irá mudar seu programa, continue lendo.
|