Se você estiver trabalhando em áreas genuinamente críticas para o desempenho, não poderá adiar a eficiência como uma reflexão tardia. É uma das coisas mais importantes a se pensar ao projetar desde o início nesses casos e de maneiras relacionadas à manutenção do resultado final.
Você não pode projetar e implementar um servidor em larga escala e apenas começar a escrever código fácil e bem documentado, que apenas usa funções de bloqueio para tudo com um bloqueio de encadeamento global que bloqueia todo o sistema para processar cada solicitação de cliente individual sem colocar nenhuma pensou em qualquer estado compartilhado, contenção de threads e assincronicidade. Essa é uma receita para o desastre e a necessidade de reprojetar e reescrever a maior parte do código bem documentado que você escreveu, de maneira a levar à base de código mais difícil de manter que se possa imaginar, atormentada pelas condições de corrida e impasses como resultado de tentar para alcançar a eficiência necessária em retrospectiva, em vez de apenas pensar em projetos eficientes, simples e funcionais antecipadamente.
Uma equipe de desenvolvimento de jogos com 8 meses de produção com um mecanismo que passa apenas 2 quadros por segundo em seu hardware mais robusto com 32 núcleos e tem uma tendência a parar por 15 segundos cada vez que a tela fica ocupada, é improvável que você obtenha instantaneamente um produto utilizável apenas consertando um pequeno ponto de acesso localizado. As chances são de que seu design seja FUBAR de maneira a garantir uma revisão épica da prancheta e as alterações de design que poderiam se espalhar em todos os cantos da base de código.
Com John Carmack, ele falou uma vez sobre como uma demonstração tecnológica deve ser executada no mínimo de centenas a milhares de quadros por segundo para integrá-la à produção. Essa não é uma obsessão doentia por eficiência. Ele sabe de antemão que os jogos precisam rodar na íntegra a mais de 30 FPS para que os clientes considerem aceitável. Como resultado, um pequeno aspecto, como um sistema de sombras suaves, não pode ser executado a 30 FPS, ou o jogo como um todo não pode ser rápido o suficiente para fornecer o feedback em tempo real necessário. É inutilizável até atingir a eficiência necessária. Nessas áreas críticas para o desempenho, em que há um requisito fundamental de eficiência, uma solução que falha em atingir a velocidade adequada não é melhor do que aquela que não funciona,. E você não pode projetar um sistema eficiente de sombras suaves que funcione de centenas a milhares de quadros por segundo, conforme necessário para um mecanismo de jogo em tempo real, a menos que você dedique uma quantidade predominante de ideias à sua eficiência. De fato, nesses casos, mais de 90% do trabalho é orientado para a eficiência, já que é trivial criar um sistema de sombra suave que funcione bem a 2 horas por quadro usando o rastreamento de caminho, mas você não pode esperar ajustá-lo para rodar a centenas de quadros por segundo sem uma mudança totalmente diferente na abordagem.
Quando a eficiência é uma parte fundamental do design de um aplicativo, você não pode esperar obter eficiência em retrospectiva sem perder muito mais tempo do que economizou ignorando-a, pois não pode esperar obter um design funcional em retrospectiva. Ninguém diz: " Não há problema em adiar o pensamento para o design até mais tarde. Apenas documente bem seu código e você poderá criar um design adequado mais tarde ". Mas em arquiteturas críticas para o desempenho, é isso que você está efetivamente fazendo se não dedicar muito cuidado e consideração a projetos eficientes antecipadamente.
Agora, isso não significa que você precisa ajustar suas implementações imediatamente. Para detalhes da implementação, há muito espaço para iterar em direção a soluções mais rápidas após a medição, desde que o design não precise ser alterado e, geralmente, essa é a maneira mais produtiva de fazê-lo. Mas, no nível do design, isso significa que você deve pensar bastante em como o design e a arquitetura se relacionarão com a eficiência desde o início.
A principal diferença aqui é o design. Não é fácil fazer grandes alterações nos designs em retrospectiva, à medida que os designs acumulam dependências, e as dependências serão quebradas se o design mudar. E se um projeto precisa ser razoavelmente eficiente ou, em alguns casos, que sua qualidade seja medida em grande parte por sua eficiência, você não deve esperar conseguir um projeto adequado como uma reflexão tardia. Com qualquer produto competitivo em que a eficiência seja um aspecto enorme da qualidade, sejam sistemas operacionais, compiladores, processadores de vídeo, traçadores de raios, motores de jogos ou motores de física, pensamentos sobre eficiência e representações de dados foram meticulosamente pensados desde o início. E nesses casos, não é uma otimização prematura colocar tanto em consideração a eficiência antecipadamente. Ele estava colocando esse pensamento exatamente no momento mais produtivo para fazê-lo,