Julio Merino é um engenheiro de software nascido em Barcelona, atualmente morando em Seattle. Recentemente, ele decidiu fazer um experimento. Resgatou um antigo PC de 2000 com um Pentium a 600 MHz, 128 MB de RAM e um disco rígido tradicional. Ao ligá-lo, ele observou algo incrível: as aplicações do Windows NT 3.51 (recentemente instalado) abriam instantaneamente.
Merino não se contentou com isso e repetiu o teste, mas com um sistema operacional mais moderno. Ele instalou o Windows 2000 na mesma máquina e, ao realizar os mesmos testes e abrir aplicações, notou que todas elas abriam instantaneamente. Os tempos de resposta eram quase inexistentes, e a sensação era de extrema rapidez. Ele explicou isso tanto no Twitter quanto em um post longo em seu blog.
Em seguida, ele fez o mesmo teste com um Surface Go 2 muito mais recente e baseado em um Core i5 a 2,4 GHz, 8 GB de RAM e uma unidade SSD. Seguindo a mesma sequência de abertura de aplicações com uma instalação limpa do Windows 11, ele observou que os tempos de abertura eram muito mais lentos. O que estava acontecendo?
Poder-se-ia dizer que esse Surface Go 2, mesmo sendo muito mais moderno do que aquele PC de 1999-2000, não tinha especificações realmente altas para executar um sistema operacional exigente como o Windows 11. Merino considerou isso e quis realizar esse teste, mas em um Mac Pro com um processador de seis núcleos a 3,5 GHz e 32 GB de RAM. Não ficou claro se ele executou o Windows com Bootcamp ou virtualização, mas de qualquer maneira, o vídeo mostrado era notável em relação aos tempos de abertura.
Como ele mesmo explicou, mesmo com as aplicações em cache, renderizá-las parecia levar muito trabalho, e elas apareciam "em pedaços". Como ele destacou, "não é por causa das animações ou de um hardware medíocre".
Também não tinha a ver com o fato de trabalhar em resolução 4K, e mesmo desativando as animações, notou-se que uma máquina e um sistema operacional modernos pareciam mais lentos do que uma máquina e um SO de mais de 20 anos atrás.
Os PCs e sistemas operacionais de 20 anos atrás não eram melhores (exceto em algumas coisas). O próprio usuário comentou em um tópico no Hacker News que sua intenção não era transmitir uma mensagem de que "as máquinas e sistemas operacionais de 20 anos atrás eram muito melhores", porque como ele disse, isso não era verdade. Na verdade, eles "eram ruins em muitos aspectos".
As coisas melhoraram em muitos aspectos, e temos computadores e software que fazem coisas impensáveis há 20 anos, tanto no desenvolvimento e execução de aplicações como em ferramentas profissionais, jogos ou conteúdos de vídeo e áudio.
Os avanços foram espetaculares, mas nem tudo parece ser melhor: as interfaces de usuário modernas tornaram-se um pouco mais lentas (mas também mais elegantes, personalizáveis e espetaculares), e mesmo em PCs e laptops de última geração pode-se notar como lançar uma aplicação pode levar mais tempo do que o esperado.
Abstração (e muitas outras coisas) são os culpados. Há várias razões para algo assim ocorrer, e uma delas é certamente como a própria evolução do software e hardware se complicou. Nossas máquinas e nosso software fazem mais coisas, mas para fazê-las bem, precisam resolver muitos problemas e garantir que os componentes de hardware e software se comuniquem ("falem") de forma adequada.
Que um usuário queira abrir uma janela do explorador de arquivos, mesmo parecendo trivial, requer que o sistema operacional converse com o hardware para que tanto o subsistema de entrada/saída quanto o subsistema gráfico (entre outros) consigam mostrar as pastas e arquivos e façam isso através de uma janela "desenhada" ou renderizada pelo hardware do chip gráfico.Essa comunicação entre o hardware e o software é realizada com as chamadas camadas de abstração de hardware (HAL, do inglês Hardware Abstraction Layer). As aplicações não acessam diretamente o hardware e seus recursos, mas sim a uma camada abstrata fornecida por essa tecnologia. Isso permite que as aplicações sejam independentes do hardware e não tenham que se preocupar com detalhes.
Mas é que às camadas de abstração se somam outros muitos componentes (e problemas) gerados pela estrutura dos sistemas operacionais modernos. Pode ser que os processos não tenham sido programados de forma assíncrona, que não haja suficiente paralelismo, ou que os sistemas de passagem de mensagens e sincronização (aqueles que estudaram esse campo certamente lembram dos mutex) não estejam totalmente ajustados.
Por si só, nos sistemas operacionais modernos há um monte de serviços e software que funcionam em segundo plano e que talvez não sejam necessários em muitos cenários. Não apenas processos do sistema, mas processos de aplicações que vamos instalando e que "pedem espaço" para se executar desde que iniciamos o PC.
De fato, até Steven Sinofsky, que foi responsável pelo desenvolvimento do Windows 7 e também do Windows 8, respondeu com um comentário também interessante: os sistemas operacionais modernos integram um navegador web, que é algo como um sistema operacional em si mesmo.
O problema da lentidão do Windows (e outros sistemas operacionais) é bem conhecido. De fato, esse comportamento confirma a conhecida lei de Wirth, que diz que "o software desacelera mais rapidamente do que o hardware acelera". Há alguns anos, os especialistas da NTDotDev realizaram uma análise detalhada de como o desempenho do Windows 10 havia piorado com o passar do tempo.
As sucessivas versões do Windows 10 -com suas grandes atualizações incluídas- chegavam com melhorias interessantes, mas também com problemas adicionados. A degradação do desempenho em certos aspectos era uma delas, e componentes como UWP ou o suporte das aplicações Win32 (as "antigas") prejudicavam a experiência do usuário em geral.
Este tipo de análise também aparecia em casos peculiares. Bruce Dawson, empregado do Google, contava há alguns meses sua particular "luta" com o gravador de voz do Windows, que demorava demais para abrir e que funcionava quase "a pedaladas".
Dawson, especialista no perfilamento de processos com ferramentas como ETW (Event Tracing for Windows) acabou analisando a trilha de execução e verificando como vários processos -e especialmente um chave, o chamado RuntimeBroker- prolongavam sua execução de forma inexplicável. Uma desenvolvedora chamada Katelyn Gadd respondia no Twitter indicando possíveis razões e dando uma opinião na qual muitos provavelmente pensam: "alguém foi provavelmente preguiçoso".
Os programadores se tornaram preguiçosos? Essa também é uma velha questão que faz referência a como os tempos mudaram em termos de hardware. Antes, os desenvolvedores se viravam para criar aplicações e jogos prodigiosos com recursos mínimos. Diz a lenda que em 1981 Bill Gates pronunciou aquela famosa frase de que "640K deveriam ser suficientes para qualquer um".
Gates negou ter dito algo assim, mas o fato é que a sensação para muitos parece ser essa: a de que os programadores "de antes" aproveitavam melhor os recursos. Como agora temos acesso a máquinas exponencialmente mais potentes e com mais recursos, "não é necessário esforçar-se tanto" na hora de criar programas eficientes porque o hardware já compensa que o código possa ser algo "preguiçoso".
Isso é verdade? Em certos casos, certamente. Vimos isso com o framework Electron, que tem sido muito usado para encapsular aplicações web e apresentá-las como aplicações nativas do Windows. Isso economizava muito tempo e esforço para as empresas desenvolvedoras de software, mas ficou demonstrado que desenvolver aplicações "nativas" faz com que a experiência do usuário e o consumo de recursos melhorem de forma notável.
Portanto, pode ser que haja desenvolvimentos preguiçosos, mas certamente não serão todos. Como vínhamos comentando, na realidade a degradação do desempenho é culpa da própria evolução da informática: nossos sistemas operacionais, nosso hardware e nosso software fazem tudo o que faziam antes e muito mais, mas para alcançá-lo é necessário contar com um bom número de componentes -alguns mais polidos que outros- que antes não tínhamos.