De 1 Semana para 30 Minutos: O que 40 anos como "Escovador de Bits" me ensinaram sobre Performance
Aplicando a mentalidade do 'Escovador de Bits', aprendida quando era preciso economizar cada byte, o autor reescreveu em C++Builder um processo moderno de importação, reduzindo o tempo de execução de uma semana para 30 minutos.
No mundo corporativo de hoje, é comum ouvirmos uma reclamação: "O sistema está lento". Processos que demoram a noite inteira a rodar, relatórios que levam horas. A resposta padrão é quase sempre a mesma: "precisamos de mais hardware", "o volume de dados é muito grande" ou "é uma limitação da ferramenta". Raramente questionamos a eficiência fundamental do código que está a correr.
Recentemente, em 2020, deparei-me com um desafio clássico de performance. A tarefa era processar dados massivos recebidos numa planilha Excel. Esses dados não eram simples; continham cerca de 600.000 registos que precisavam ser validados, cruzados e convertidos em mais de 40 modelos diferentes de scripts Oracle para serem importados por um sistema central.
Havia uma aplicação existente que fazia esta tarefa. O seu tempo de processamento era de uma semana. Sim, uma semana de máquina a processar para converter uma única planilha.
Decidi reescrever a solução do zero. Usei o C++Builder, uma ferramenta que domino há décadas, e apliquei a lógica que aprendi ao longo de 40 anos de desenvolvimento. O resultado: a nova aplicação executa o mesmo processo, com os mesmos 600.000 registos em 30 minutos.
Como é possível uma discrepância tão brutal? Não foi magia. Foi o resultado de uma mentalidade que a indústria moderna, com a sua abundância de recursos de hardware, esqueceu: a mentalidade do "Escovador de Bits".
Quando comecei a programar nos anos 80 e 90, os recursos eram bem mais escassos. O espaço em disco e a memória eram contados milimetricamente. Fomos a geração que, por padrão, usava dois dígitos para o ano (YY) em vez de quatro (YYYY), apenas para economizar dois bytes por cada data armazenada. Éramos forçados a pensar na forma mais eficiente de guardar um dado, não porque era "boa prática", mas porque era a única forma de a aplicação funcionar. Nós não otimizávamos no final: nós desenhávamos para a otimização desde o primeiro byte.
Esta mentalidade obriga-nos a entender o que acontece por baixo das camadas de abstração. Lembro-me dos tempos do QNX, tínhamos um bug catastrófico onde o sistema operacional perdia o boot se faltasse a energia. A solução não estava em nenhuma biblioteca; o sistema simplesmente não iniciava. A única forma de resolver foi analisar o disco rígido setor por setor, a olhar para os bytes, até descobrir que o problema eram apenas nos dois primeiros bytes do HD que estavam invertidos (leia também o artigo "O Cérebro da Operação – Desvendando o QNX" que conta a história da criação do mapa.ces).
Quando passamos décadas a resolver problemas nesse nível, nível do byte, do setor de disco, da comunicação serial direta, desenvolvemos uma compreensão fundamental de como a máquina realmente processa a informação.
Os frameworks modernos e as linguagens de alto nível são ferramentas fantásticas de produtividade, mas escondem o custo real das operações. Elas facilitam a criação de código funcional, mas também facilitam a criação de um código terrivelmente ineficiente, no que tange performance.
A lição que fica é que a performance, real raramente vem de mais hardware. Ela vem da arquitetura, ela vem do algoritmo. Ela provém também de entender o problema fundamental e de usar a mentalidade do "escovador de bits" para garantir que o computador vai fazer apenas o trabalho necessário, da forma mais direta possível. A experiência de 40 anos não é sobre saber ferramentas "antigas"; é sobre saber os fundamentos que permitem que uma tarefa de uma semana seja, afinal, em 30 minutos.
Este artigo é baseado numa história de "Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código", as memórias do autor.
Leia a história completa aqui.