Performance e Qualidade do Software Caiu? - Parte I

Muitos leitores do meu finado blog pessoal (espero trazer ele do cemitério digital dia desses) no Gardenal.org sabem que sou absolutamente fissurado por performance dos equipamentos e softwares. Entenda-se por isso realizar uma tarefa qualquer, de maneira estável, consumindo o mínimo de memória e processamento.

Bem, posso declarar categoricamente que estamos mal. Nunca se escreveu tanto software consumista, os "bloatwares" e "resource hogs", expressões em inglês para definir programas que fazem tarefas e consomem recursos demais. Querem um exemplo? Azureus vs uTorrent. Quem já usou esses programas pode notar a diferença entre um consumir 100MB ou mais de memória e deixar sua CPU acima de 20% praticamente o tempo todo e o segundo, consumindo entre 5 e 7MB de memória e a CPU ficar entre 3% e 8% de consumo. Um único executável de 115kb com tudo o que você realmente precisa.Programas enxutos, que usam cada ciclo do processamento e cada bit de memória ao seu favor estão cada vez mais raros hoje em dia. Ainda existem muitos, é claro, mas cada vez mais vemos programas nativos cederem terreno. É preciso garimpar muito e instalar pelo menos uns 4 produtos diferentes. Fiz isso com anti-vírus, para descobrir que o AVG e o Nod32 são os mais econômicos, por exemplo. Com um computador entry-level possuindo 512MB de RAM e processador de 2GHz, não é de se surpreender que o poder bruto de processamento esconde a falta de otimização na produção de software. O Avast, por exemplo, inicializava a máquina com 5 ou 6 processos diferentes, deixou a inicialização lenta e consumiu, no boot, mais de 60MB de memória.

Mas a culpa não é do Java ou do .Net como muitos dizem. Essas duas plataformas surgiram para eliminar trabalho tedioso de muitas aplicações, que não exigem ultra-performance no Desktop e aplicativos de servidor, evitando reescrever ou recompilar código. Um amigo meu, especialista em Java, certa vez me mostrou como um aplicativo bem escrito e testado, rodando num servidor ultrapassou a performance de um mesmo programa fazendo tarefa semelhante em código nativo. E ele disse mais ou menos assim: "Se o Java, com a Virtual Machine roda mais rápido que o código nativo, então quer dizer que ele foi muito bem escrito e é esse tipo de software que precisamos num servidor de aplicações críticas." Concordo totalmente com ele e o mesmo vale para a .Net Framework, na plataforma Windows ou no Linux usando Mono.

Os fanáticos por Java, nos anos 90, achavam que era a panacéia universal, para logo em seguida os usuários rejeitarem porque a performance era ruim. Lembram páginas pinhadas de applets Java? Quem chegou recentemente na Internet, pode nem nunca ter ouvido falar disso. Os applets perderam terreno para o Flash, JavaScript, e HTML puro, cercados por XML com muito gosto. Pessoas se matriculavam em cursos de Java para aprender a fazer applets Java e nem se importavam com a linguagem ou a arquitetura que ela representava. A dita Web 2.0 nada mais é que usar padrões definidos pela W3C.org e deixar linguagens de programação mais robustas no lado do servidor.

Existem necessidades reais para processadores mais rápidos. O stream de vídeo, por exemplo, seria impraticável com os 486 e até mesmo com a primeira geração de Pentium, porque falta a eles a capacidade de processamento, em tempo real, de descomprimir o vídeo e som, mantê-los sincronizados e ainda por cima gerenciar outras aplicações. O processador ficaria em seu máximo o tempo todo, para um vídeo pequeno. Estamos falando de uma época em que HDs ainda eram menores que a capacidade de um CD-ROM. Usar periféricos como câmeras digitais ou filmadoras e a edição dos filmes e fotos gerados pelos mesmos exigem muito processamento e memória, mas fico sempre com a impressão que poderia ser melhor. Basta ver aplicações para portáteis: com um equipamento inferior em todos os quesitos em relação a um desktop, eles se comportam como um desktop e a performance é excelente. Quando não é, você nota na hora e parte para outro produto.

Nos handhelds, tudo importa e não deve haver pontas soltas. Nada de arquivos de configuração deixados para trás, pois há limites de memória. Ao remover algo, ele é retirado totalmente do equipamento. Cada ciclo do processador de texto é levado em consideração, para não haver desperdício de bateria. Já no desktop, com o consumo constante, estamos comprando fontes reais de 400 watts e com o risco de não dar conta. Drivers de vídeo e som inteligentes e auto-configuráveis possuem um custo alto. Os drivers da ATI exigem a .Net Framework para funcionar, caso queira usar a ferramenta de configuração. Fiquei órfão, pois eu sempre usei a ferramenta nativa, leve, pequena e muito eficaz.

É claro que sou realista quanto ao uso de cada um, mas o ponto-chave é: se o software que é escrito para computadores pessoais tivesse o mesmo cuidado que um programa escrito para PocketPC ou um Smartphone, veríamos que o processador de 1.2GHz que você considerava um lixo é, na verdade, excelente. A vida útil dele foi ceifada por uma saraivada de programas pedindo cada vez mais e realizando as mesmas tarefas: anti-vírus, firewall, programas de escritório, players de som e vídeo.