Por que os tamanhos dos programas são tão grandes?

Se observarmos o programa vintage Netscape Navigator ou uma versão anterior do Microsoft Word, esses programas tinham tamanho inferior a 50 MB. Agora, quando instalo o google chrome, ele tem 200 MB e a versão desktop do Slack, 300 MB. Eu li sobre alguma regra que os programas terão toda a memória disponível, não importa quanto, mas por quê?

Por que os tamanhos atuais de programas são tão grandes em comparação com 10 ou 15 anos atrás? Os programas não estão executando significativamente mais funções e não parecem muito diferentes. O que é que é o porco do recurso agora?

"Parecer muito diferente" é uma questão de percepção. Os gráficos de hoje precisam ter uma resolução de tela totalmente diferente da que costumavam ser, com o resultado de que uma imagem de 100x100 que costumava ser mais do que suficiente para um logotipo agora fica terrivelmente pegajosa. Ele teve que ser substituído por uma imagem de 1000x1000 da mesma coisa, que é um fator de 100 ali. (Eu sei que você pode usar gráficos vetoriais, mas isso apenas enfatiza o ponto - o código de renderização de gráficos vetoriais teve que ser adicionado a sistemas que não precisavam dele antes, então isso é apenas uma troca de um tipo de aumento de tamanho para outro.)

"Trabalhar de maneira diferente" também é uma questão de percepção. O navegador de hoje faz muito mais do que um, desde 1995. (Tente navegar na Internet com um laptop histórico em um dia chuvoso - você achará quase inutilizável.) % deles, mas estão lá.

Além disso, é claro, há a tendência geral de gastar menos tempo na otimização de espaço e mais na introdução de novos recursos. Esse é um efeito colateral natural de computadores maiores, mais rápidos e mais baratos para todos. Sim, seria possível escrever programas tão eficientes em termos de recursos quanto em 1990, e o resultado seria surpreendentemente rápido e preciso. Mas não seria mais econômico; seu navegador levaria dez anos para ser concluído, quando os requisitos teriam mudado completamente. As pessoas costumavam programar com extrema atenção à eficiência, porque as máquinas pequenas e lentas do passado as obrigavam, e todo mundo fazia isso também. Assim que isso mudou, o gargalo para o sucesso do programa deixou de ser capaz de executar em tudo a corrermais e mais coisas brilhantes , e é aí que estamos agora.

Se você comparar o Netscape Navigator a um navegador moderno, há uma enorme diferença na funcionalidade. Basta comparar a especificação do HTML 3.2 (51 páginas quando eu faço uma visualização de impressão) com a especificação do HTML atual (a versão em PDF é 1155 páginas). Isso é um aumento de 20x no tamanho.

O Netscape Navigator não tinha um DOM e não tinha CSS! Não houve alterações dinâmicas no documento, nenhum JavaScript modificou o DOM ou as folhas de estilo. Sem guias. Sem áudio ou vídeo. Um navegador moderno é um programa muito mais complexo.

Uma razão é que os dados empacotados nos aplicativos são maiores porque são de maior resolução e qualidade. Um ícone na época do Netscape tinha no máximo 32x32 pixels, com profundidade de 8 bits (possivelmente apenas 4), enquanto agora provavelmente é algo como 64x64 e está em cores reais com transparência, o que significa profundidade de 32 bits. Isso é 16 vezes maior. E o espaço é tão barato que as pessoas nem se dão ao trabalho de verificar a opção "compactado" ao gerar um PNG.

Outro motivo é que hoje em dia os aplicativos carregam uma quantidade impressionante de dados, o que os aplicativos mais antigos não possuíam. Hoje existem aplicativos que são enviados juntamente com uma apresentação de "introdução" em vídeo .

Outro motivo é que as linguagens de programação atuais tendem a combinar com ambientes ricos em tempo de execução, que são razoavelmente grandes, na faixa de 100 MB cada. Mesmo se você não usar todos os recursos do seu ambiente de tempo de execução, ainda precisará empacotar tudo com seu aplicativo.

Mas a principal razão é que hoje existem toneladas e muitas bibliotecas por aí que podemos usar em nossos aplicativos, e desenvolvemos uma cultura de uso de bibliotecas para evitar a constante reinvenção da roda. Obviamente, uma vez que você começa a usar bibliotecas, várias perguntas aparecem e nós desenvolvemos o hábito de dar as respostas mais liberais para elas:

• Vale a pena incluir mais uma biblioteca se ela for usada por apenas uma de minhas funções? - Sim.

• Vale a pena incluir mais uma biblioteca se eu precisar apenas de um pequeno subconjunto de toda a riqueza de funcionalidades oferecidas por essa biblioteca? - Sim.

• Vale a pena incluir mais uma biblioteca se a sua inclusão me salvar de 2 dias de trabalho? - Sim.

• Vale a pena incluir várias bibliotecas que atendem mais ou menos ao mesmo objetivo, apenas porque diferentes programadores na minha folha de pagamento já estão familiarizados com diferentes bibliotecas? - Sim.

  (Observe que estou apenas observando essas tendências, não estou fazendo nenhuma declaração quanto a concordar ou discordar delas.)

Outro motivo que vale a pena mencionar é que, ao tentar decidir qual aplicativo usar entre várias opções, alguns usuários pensam que aquele que ocupa mais espaço terá mais recursos, terá gráficos mais sofisticados etc. (o que é um absurdo completo, é claro .)

Então, para concluir, o software se comporta como o gás? Tende a ocupar todo o espaço disponível? Em certo sentido, sim, mas não de forma alarmante. Se olharmos para o que ocupa mais espaço em nossas unidades, para a maioria de nós, a resposta é que não são aplicativos, mas mídias, como filmes e música, de longe . O software não tem inchado na mesma proporção em que a capacidade de armazenamento está se expandindo, e é improvável que isso aconteça, portanto, no futuro, os aplicativos provavelmente representarão uma fração desprezível do espaço de armazenamento disponível para os usuários.

Além dos outros ansers, há dez anos, normalmente havia versões separadas para versões localizadas / internacionalizadas. Agora é geralmente o caso de programas oferecerem suporte completo à localização em todas as versões lançadas que atendam ao tamanho do programa.

Uma razão é dependências. Um programa com funcionalidade rica e boa aparência precisa de muitas coisas - criptografia, verificação ortográfica, trabalho com XML e JSON, edição de texto e muitas outras coisas. De onde eles viriam? Talvez você faça o seu próprio e mantenha-o o menor possível. Provavelmente você usa componentes de terceiros (de código aberto licenciado pelo MIT, talvez) que possuem muitas funcionalidades que você realmente nunca precisa, mas depois que você precisa de uma única função de um componente de terceiros, geralmente precisa carregar todo o componente. Assim, você adiciona cada vez mais dependências e, à medida que elas próprias evoluem e crescem, seu programa que depende delas também cresce.

Embora os gráficos / usabilidade sejam de fato fatores contribuintes, há uma quantidade enorme de códigos compilados em excesso de biblioteca / excesso.

Exemplo de como o código ainda pode ser pequeno: MenuetOS, um sistema operacional completo de 64 bits com aplicativos poderosos que se encaixam em um único disquete.

Exemplo de como o código pode ser grande sem motivo óbvio: criei uma saída de texto simples "Olá, mundo!" em Ada recentemente. O executável compilado tinha mais de 1 MiB !. O mesmo executável no assembly é apenas um KiB ou 2 (e a maior parte disso é sobrecarga executável, o código em execução real é dezenas de bytes).

É trivialmente verdade que o software precisa ser construído para se ajustar a duas coisas: os usuários e o hardware disponível. Um programa é adequado a sua finalidade se ele faz o que o usuário deseja em tempo hábil com o hardware à sua disposição. Bem, duh. Mas, à medida que o hardware melhora basicamente todas as dimensões mensuráveis, aumenta o número de programas discretos que passam do impróprio para o adequado - o espaço do design aumenta:

• Linguagens de nível superior tornam possível expressar idéias em menos tempo e código do que antes. Essa complexidade reduzida, por outro lado, torna possível expressar idéias cada vez mais complexas.
• Agrupar mais dados com o aplicativo pode torná-lo instantaneamente mais utilizável. Por exemplo, provavelmente não demorará muito para que os aplicativos de verificação ortográfica sejam incluídos em todos os idiomas conhecidos pela humanidade - são apenas alguns gigabytes, afinal.
• Os trade-offs de hardware permitem que desenvolvedores e usuários tenham mais opções de recursos. Veja, por exemplo, índices de banco de dados FLAC / OGG vs WAV, SVG vs PNG.
• Interfaces humanas geralmente trocam o que anteriormente equivaleria a grandes quantidades de hardware para usabilidade. Anti-aliasing, altas resoluções, atualização rápida e troca entre o que equivale a painéis discretos contribuem para uma experiência mais realista e, portanto, intuitiva e relacionável.

Definitivamente, isso vale para aplicativos Android. Há quatro anos, um aplicativo simples ocupava espaço de 2 a 5 megabytes. Atualmente, um aplicativo simples ocupa cerca de 10 a 20 megabytes de espaço.

Quanto mais espaço disponível, maior o tamanho do aplicativo.

Eu acho que existem duas razões principais no caso do Android:

• O Google expandiu a estrutura do Android, adicionou muitas novas funcionalidades.

• Os desenvolvedores não se importam mais. As imagens são incluídas em uma resolução muito mais alta (é claro que as resoluções de tela do smartphone aumentaram), as bibliotecas de terceiros são incluídas sem pensar.

Muito disso se resume ao tempo do desenvolvedor e ao custo desse tempo. Nos dias em que o Visual Basic chegou à cena, ele estava competindo com C / C ++ e a grande vantagem foi que você poderia escrever 'Hello World' no ANSI C para Windows em talvez 15K. O problema com o VB era que você sempre teve o albatroz da biblioteca de tempo de execução de 300K.

Agora, você poderia 10x o tamanho do seu programa VB e ainda seria apenas mais alguns K, mas 10x o tamanho do seu programa C / C ++ e você está olhando para alguns meses a mais de desenvolvimento.

No final, o inchaço de seus aplicativos é um preço pequeno a pagar pelos enormes saltos na produção de desenvolvimento, redução de preço e enorme vastidão de recursos que nunca seriam possíveis nos velhos dias de desenvolvimento artesanal; quando os programas eram pequenos e rápidos, mas também fracos, incompatíveis entre si, com pouco desempenho e desenvolvimento dispendioso.

Com o tempo, as necessidades do usuário estão evoluindo e se tornando cada vez mais exigentes, de modo que fornecedores / autores de diferentes softwares são forçados a satisfazer essas necessidades em nome da concorrência.

Mas satisfazer uma nova necessidade significa muitas vezes adicionar novo código. Novo código significa novas vulnerabilidades para corrigir. A correção de novas vulnerabilidades pode adicionar código ou abrir portas para novas vulnerabilidades.

Cada recurso adicionado para satisfazer a necessidade de um usuário pode precisar de mais potência do processador para velocidade (todos reclamamos da velocidade deste ou daquele navegador), novos recursos gráficos para melhores efeitos visuais ... etc.

Tudo isso significa adicionar novas camadas de aplicativos (código), segurança e, às vezes, hardware.

Muito do tamanho vem de bibliotecas integradas. Atualmente, muitas aplicações são construídas usando elétrons, que agregam uma quantidade enorme à aplicação. Se você instalar aplicativos no Linux, eles geralmente são muito menores, porque grande parte do aplicativo já está instalado através de bibliotecas compartilhadas que outros programas também estão usando.

Ao construir um software, se você precisar da função A, importará um módulo A *. A * pode resolver A, mas A * pode resolver problemas mais do que A, e A * pode ser grande. Todos os módulos grandes resultam no software de tamanho grande.

Talvez não seja o mesmo caso, mas algo como isto: Se você só precisa imprimir "olá mundo" no console usando Java, precisa do JRE (> 60 MB) instalado.

Se o exemplo de Java não for bom, tente o seguinte: Se o software precisar fazer logon no arquivo, ele poderá usar um módulo de log que pode realmente fazer logs no banco de dados, na rede e em alguns outros recursos, mas as funções nunca são usadas no o projeto.

Eu li sobre alguma regra que os programas terão toda a memória disponível, não importa quanto, mas por quê?

Isso não é bem verdade. Os sistemas não liberarão a memória consumida até que o sistema operacional fique sob pressão da memória. Isso é uma melhoria de desempenho. Se você estava navegando em uma página com imagens, navegava para longe. Você pode navegar de volta, precisando, portanto, da imagem novamente. Se o sistema operacional tiver RAM, não há sentido em limpar a memória até ter certeza de que não será necessário novamente.

Limpar a memória imediatamente levaria os ciclos da CPU e a largura de banda da memória para longe do usuário quando eles provavelmente desejam que páginas da web altamente responsivas sejam exibidas na tela.

O sistema operacional consumirá toda a memória disponível fora do aplicativo, a maioria destinada ao cache do sistema de arquivos.

O gerenciamento de memória é um problema difícil, mas há pessoas muito inteligentes trabalhando nele o tempo todo. Nada está sendo desperdiçado de propósito e o objetivo principal é fornecer um computador muito responsivo.

Pode ser verdade que os programas tendem a se expandir para preencher o espaço disponível, semelhante aos fenômenos suburbanos, nos quais você adiciona novas faixas a uma rodovia superlotada e, em poucos anos, o backup é feito novamente.

Mas se você analisar, poderá descobrir que os programas realmente fazem mais coisas. Os navegadores, por exemplo, executam gráficos mais sofisticados, possuem excelentes ferramentas de desenvolvedor que não existiam há alguns anos, etc. Eles também se vinculam a muitas bibliotecas, às vezes usando apenas uma pequena parte do código. Portanto, embora os programas possam aumentar de tamanho para preencher a memória disponível, alguns deles podem ser razões legítimas.

As bibliotecas criadas em objetos que não são otimizados requerem mais memória para carregar, instalar e mais ciclos de computação para operar. O código do objeto é, em grande parte, inchado.

Basta percorrer o código C ++ padrão em execução para ver todas as chamadas de objeto assert () ed para garantir que eles sejam objetos válidos. Quando você cria camadas sobre camadas de objetos que encapsulam objetos, os underlayers ficam inchados e opacos. Os programadores ficam preguiçosos e enfrentam mais objetos porque é mais rápido do que redesenhar o que é limitado à funcionalidade necessária. É realmente assim tão simples.

Considere o tamanho do kernel Linux C, apenas o kernel, versus o tamanho dos aplicativos sob medida. O kernel pode executar a máquina inteira. Mas não foi construído tão rapidamente quanto os aplicativos, leva tempo lentamente para criar a melhor funcionalidade.