Inflação de software em termos de recursos do processador - por que as versões mais recentes do aplicativo às vezes são muito mais lentas que as anteriores?

Prelúdio

Era uma noite de quinta-feira regular. Voltei do trabalho, sentei-me no laptop, liguei-o, iniciei o Skype e comecei a esperar habitualmente que ele finalmente inicializasse completamente e completamente. E, de repente, pensei - por que demorou tanto tempo para carregar e até o sistema é claramente difícil de suportar esse processo?

Decidi examinar o Gerenciador de tarefas para estimar quanto de recursos o Skype consome em segundo plano. Mas primeiro, alguns cálculos preliminares. E quanto isso deve consumir recursos? Eu estou falando sobre o fundo agora. Essa. quando não há conexão de vídeo, nem falo com o microfone com ninguém. Tudo o que é é uma lista de contatos, exibida na forma de ícones e nomes, e um menu no qual você pode escolher alguma coisa.

Essa. de fato, esse é um formulário a partir do qual você pode iniciar menus adicionais. Há uma lista neste formulário. E uma caixa de texto para inserir mensagens para alguém, alguns botões. Cerca de 15 anos atrás, quando escrevi em Delphi, esse aplicativo (com um formulário) pesaria algumas centenas de kilobytes. Obviamente, desde então, o ambiente de desenvolvimento começou a consumir muito mais recursos, os componentes visuais ficaram mais ricos. No entanto, mesmo com esse progresso, o Skype em segundo plano deve pesar algo em torno de 10 megabytes no máximo. Afinal, não estou conversando ou ligando para ninguém, o que mais posso gastar tanto lá?

Você pode olhar para esse assunto e, por outro lado, como dizem os matemáticos, equivalência. Sem chamadas de vídeo e conversas com microfone, o Skype oferece uma oportunidade de ver qual dos interlocutores está atualmente na rede, além de enviar-lhe uma mensagem de texto e receber uma mensagem de texto em resposta de alguém. Essa. esse é essencialmente o ICQ - então, bem, provavelmente em segundo plano, provavelmente, o Skype deve ocupar tanto quanto o ICQ na memória? Agora vamos verificar na prática esses cálculos. Observamos o consumo de memória no TaskManager:



O Skype ocupa 158 MB de memória? Você está falando sério, considerando que o QIP é de 35 MB? Ok, 35 MB provavelmente é demais, e isso deve ser resolvido, mas minha observação não é sobre isso. Agora estamos falando do Skype. Por que consome tantos recursos - quase 5 vezes mais que o QIP? É um pouco demais para um formulário com uma lista de contatos, não é?

Curiosamente, esse problema não me excita, se você acessa o Google " Por que o skype consome tanta memória ", então apenas um monte de discussões nos fóruns desaparecem , por que as novas versões do Skype pesam tanto. As respostas são especialmente agradáveis. Por exemplo, uma resposta real no fórum da comunidade Skype (cito minha tradução gratuita da resposta):

, ? 4-8 . 140 , .

Sim sim. Claro. Nesse caso, todos os desenvolvedores de software raciocinam, dessa forma " nenhum aumento não é suficiente ". A questão não é que sinto muito pela memória do Skype (e também sinto muito). A questão é: o que há de tão novo em funcionalidades adicionadas nas novas versões do Skype (em comparação com as antigas), que exigem tanta memória?

Mas tudo bem: eu estava mais interessado em outra pergunta - o processador com o Skype em segundo plano também não relaxou e mostrou periodicamente até uma carga completa. Surge a pergunta: "Por que e como se livrar disso?". De fato, a pergunta deve soar assim - como os desenvolvedores conseguem criar aplicativos tão volumosos? E o que fazer com isso?

Um pouco de história

Certamente, qualquer visitante deste site provavelmente pelo menos uma vez ouviu falar da lei de Moore sobre como melhorar o desempenho do sistema. O artigo O almoço grátis acabou fornece uma imagem tão curiosa:



Como você pode ver, em algum lugar de 2004, os processadores atingiram o teto em termos de frequência de clock. E nos últimos 10 anos, essa frequência não está crescendo particularmente. Daqui resulta que a lei de Moore deixou de ser cumprida? Na verdade, não, e o artigo explica de maneira clara e clara o porquê. Simplesmente, o desempenho de nossos computadores agora está aumentando devido a outros fatores (cache e multicore). O problema, porém, é que aplicativos normais de thread único não serão capazes de acelerar esses fatores. E aqui está o problema. O fato é que hoje muitos fabricantes de software se comportam como se o quintal ainda estivesse nos anos 80 ou 90, e otimizar o software em termos de redução do número de ciclos de clock não representa um problema específico - você pode esperar um pouco e os processadores irão muito mais rapido.

Isso é verdade não apenas para a Microsoft, mas vou me concentrar em exemplos específicos. Joel Spolsky em seu artigo menciona que a Microsoft conseguiu prevalecer sobre a Lotus nos anos 80 na batalha entre o Excel e o 123, devido ao fato de que os gerentes da Lotus cometeram um erro crítico - tentaram otimizar o aplicativo. Especificamente, eles tentaram reduzir o aplicativo para garantir que ele cabesse sempre em 640 KB de RAM. Eles o mataram por um ano e meio e, durante esse período, Redmond conquistou o mercado usando o Excel, porque naquele momento computadores com quantidades muito maiores de RAM estavam em operação. Essa solução custou muito à Lotus.

No entanto, eis o que é interessante - atualmente, essa estratégia pode se tornar uma vitória - já que os recursos dos sistemas de desktop padrão não crescem mais em um ritmo tão incrível quanto há 20 a 30 anos. O problema é que, como resultado da concorrência acirrada daquele período, as empresas que desenvolveram a funcionalidade dos aplicativos foram as vencedoras, ignorando o desempenho e a otimização. São essas empresas que formaram essa ideologia de desenvolvimento, cujos frutos ainda estamos colhendo.

Inflação

O que isso levou? Para um fenômeno muito curioso. Nunca vou desistir de atualizações de hardware, mas, de repente, comecei a evitar atualizações de software desnecessariamente, devido a uma possível inflação . Com esse termo, quero dizer que o mesmo conjunto funcional que eu tinha na versão antiga, na nova, recebia um ótimo preço em termos de recursos do processador e RAM.

Existe um idioma constante em inglês, que em russo soa como "tentar consertar algo que não foi quebrado". A situação com o software nos últimos 10 anos lembra muito esse idioma. O Skype é um dos principais exemplos disso. A julgar pelos fóruns, esse problema de memória não existia nas versões mais antigas do Skype, por exemplo, nas versões 3.x. O que foi aprimorado no produto desde então que se tornou tão caro em termos de RAM?

O mesmo, a propósito, se aplica a vários aplicativos de bate-papo. Há cerca de 15 anos, o bate-papo, que ocupa 30 MB de RAM, parecia um absurdo. No entanto, agora essa já é a norma, embora o que as salas de bate-papo atuais nos forneçam, que não eram fornecidas naquele momento?

Não se esqueça do Microsoft Office. Na minha opinião, a versão para XP satisfez a todos. Obviamente, como qualquer produto, ele tem suas desvantagens. Mas eles eram tão críticos que precisavam lançar as versões 2007, 2010 etc.? Faço os mesmos documentos neles, mas agora tenho que esperar muito mais tempo até que esses sistemas sejam inicializados.

Como justificativa, ouvimos dizer que novas versões contêm novos recursos. Sim, não nego, mas não parece estranho que, ao fazer isso, as antigas oportunidades exijam mais recursos?

Modularidade e Otimização

Ainda assim, por que mais recursos? Aqui tudo é explicado pelo fato de que a maioria das aplicações é bastante monolítica. Não, em termos de organização do código, eles provavelmente são divididos em módulos com a divisão de responsabilidade correta. No entanto, eu os chamo de monolíticos, no sentido de que, ao carregar um aplicativo, todos os seus módulos geralmente são carregados imediatamente, embora isso geralmente não seja necessário.

Voltaremos novamente ao Skype. Agora é obviamente feito para que, com um login simples, muitos módulos sejam carregados imediatamente na RAM, os quais são diretamente responsáveis ​​por som, vídeo etc. Isso ocorre apesar do fato de que a entrada usual requer apenas uma lista de usuários e a capacidade de trocar texto. Este sistema pode ser feito de maneira diferente, carregando apenas o mais necessário. E somente quando o usuário realmente deseja iniciar uma troca de vídeo, todo o resto é carregado.

A otimização também é importante, devido ao fato de que os desenvolvedores são fisicamente incapazes de desenvolver todo o código do zero, mas são forçados a usar as bibliotecas existentes que foram escritas sem muita pressão na otimização.

Imagine que o desenvolvedor de cada biblioteca tornasse sua biblioteca 5% mais lenta do que poderia ter sido se ele tivesse gasto esforços adicionais em otimização. Deixe a biblioteca 1 usar a biblioteca 2 em seu trabalho, e a biblioteca 3 e a biblioteca 4. Nesse caso, uma cadeia de 15 bibliotecas no caso de acumulação de atrasos obtém o resultado 1,05 ^ 15 = 2,07, ou seja, na pior das hipóteses, o aplicativo será executado duas vezes mais lento que qualquer um dos componentes.

Conheço bem a frase de que a otimização prematura é a raiz de todo mal. No entanto, essa é uma otimização prematura, não otimização. Esse slogan foi maravilhoso no momento em que os processadores estavam ficando cada vez mais rápidos diante de nossos olhos. Depois de atingir o teto, esse slogan começa a virar de lado, quando a versão antiga do aplicativo, escrita há cerca de 15 anos, repentinamente começa a parecer mais preferível do que a versão lançada na semana passada. A propósito, não se pode deixar de notar o fato de que frequentemente os fabricantes de software tentam forçar os usuários a atualizar o software, precisamente porque não existem motivos especiais para o benefício do consumidor nesse caso.

Exemplos alternativos

Em princípio, a indústria de software espera o mesmo que a indústria automotiva após a crise do petróleo nos anos 70, quando ficou claro que a gasolina estava se tornando um recurso extremamente caro. Desde então, as montadoras conseguiram reduzir o consumo de motores em cerca de um terço, se não me engano.

No mundo do software, também existem exemplos. Ao mesmo tempo, gostei muito do Erlang, que se baseia no conceito de muitos processos leves independentes, unidos apenas por mensagens comuns (isso permite maximizar o uso do multicore). Além disso, existe um princípio nesse ambiente que foi explicitamente emprestado dos intérpretes LISP - que cada módulo e função pode ser carregado e recarregado em movimento, se necessário (e o mesmo se aplica a qualquer processo).

Para comparação, no Glassfish, se você alterou uma de várias centenas ou milhares de classes, precisará reinstalar o módulo inteiro (war / ear / jar). A troca a quente de funções ou classes em movimento está lá, mas é implementada muito mal em comparação com o Erlang.

O futuro do setor reside em aplicativos que podem utilizar totalmente a tecnologia multinúcleo e não fazem o download imediato de todos os módulos possíveis para todos os recursos deste produto. Essa. o programa poderá carregar a configuração básica e consumir tantos recursos quanto seu antecessor consumido há 15 anos e, se necessário, baixar tudo o que o usuário precisar em movimento.