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

"Parecer muito diferente" é uma questão de percepção. Os gráficos de hoje têm que ter uma boa aparência em resoluções de tela totalmente diferentes do que costumavam, com o resultado de que uma imagem de 100x100 que costumava ser mais do que suficiente para um logotipo agora seria horrivelmente brega. Ele teve que ser substituído por uma imagem de 1000x1000 da mesma coisa, que é um fator de 100 ali mesmo. (Eu sei que você pode usar gráficos vetoriais em vez disso, 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 disso antes, então isso é apenas um trade-off de um tipo de aumento de tamanho para outro.)

"Trabalhar diferentemente" é também uma questão de percepção. O navegador de hoje faz maciçamente mais coisas do que um de 1995. (Tente navegar na internet com um laptop histórico em um dia chuvoso - você verá que é quase inutilizável.) Não muitos deles são muito usados, e usos podem ser completamente inconscientes de 90% deles, mas eles estão lá.

Além disso, é claro, a tendência geral é gastar menos tempo na otimização de espaço e mais na introdução de novos recursos. Este é um efeito colateral natural de computadores maiores, mais rápidos e mais baratos para todos. Sim, seria possível escrever programas que sejam tão eficientes em termos de recursos como eram em 1990, e o resultado seria incrivelmente rápido e liso. Mas não seria mais rentável; 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 de antigamente as forçavam a fazê-lo, e todos os outros o faziam também. Assim que isso mudou, o gargalo para o sucesso do programa mudou de ser capaz de rodar para executar mais e mais coisas brilhantes , e é aí que estamos agora.

Se você comparar o Netscape Navigator com um navegador moderno, há uma diferença maciça na funcionalidade. Basta comparar a HTML 3.2 Spec (51 páginas quando eu fizer uma pré-visualização) com o current HTML Spec (a versão PDF é 1155 páginas). Isso é um aumento de 20x no tamanho.

O Netscape Navigator não tem um DOM e não tem CSS! Não houve alterações dinâmicas do documento, nenhum JavaScript modificando o DOM ou as folhas de estilo. Nenhuma aba Sem áudio ou vídeo. Um navegador moderno é um programa vastamente mais complexo.

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

Outra razão é que as aplicações hoje em dia carregam uma quantidade incompreensível de dados com elas, o que as aplicações mais antigas não tinham. Existem aplicativos hoje que são enviados juntamente com uma apresentação "em início" em vídeo .

Outra razão é que as linguagens de programação hoje tendem a ser combinadas com ambientes rich run-time, que são razoavelmente grandes, com até 100MB cada. Mesmo se você não usar todos os recursos do seu ambiente de tempo de execução, ainda precisará empacotar tudo com o aplicativo.

Mas a principal razão é que hoje existem toneladas e toneladas de bibliotecas que podemos usar em nossos aplicativos, e desenvolvemos uma cultura de usar bibliotecas para evitar a constante reinvenção da roda. É claro que, quando você começa a usar bibliotecas, várias perguntas surgem e desenvolvemos o hábito de dar as respostas mais liberais a elas:

• Vale a pena incluir ainda outra biblioteca se ela for usada por apenas uma das minhas funções? - sim.

• Vale a pena incluir ainda outra biblioteca se eu precisar apenas de um pequeno subconjunto de toda a riqueza de funcionalidades oferecidas por essa biblioteca? - sim.

• Vale a pena incluir outra biblioteca se a inclusão dela só me poupar de dois dias de trabalho? - sim.

• Vale a pena incluir várias bibliotecas que atendem mais ou menos a mesma finalidade apenas porque diferentes programadores em minha folha de pagamento já estão familiarizados com diferentes bibliotecas? - sim.

  (Por favor, note que eu estou apenas observando essas tendências, eu não estou fazendo nenhuma declaração sobre se eu concordo ou discordo deles.)

Outra razão que vale a pena mencionar é que, ao tentar decidir qual aplicativo usar entre várias opções, alguns usuários acham que aquele que ocupa mais espaço será mais cheio de 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 para isso? 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, de longe. O software não tem inchado na mesma proporção que a capacidade de armazenamento está se expandindo, e é improvável que isso aconteça, então no futuro os aplicativos provavelmente representarão uma fração desprezível do espaço de armazenamento disponível para usuários.

Em adição aos outros ansers, há 10 anos tipicamente haveria versões separadas para versões localizadas / internacionalizadas. Agora, geralmente, os programas agrupam o suporte de localização completo em todas as versões lançadas que preenchem o tamanho do programa.

Um dos motivos é dependências. Um programa com funcionalidade rica e boa aparência precisa de muita coisa - criptografia, verificação ortográfica, trabalho com XML e JSON, edição de texto e muitas outras coisas. De onde eles vêm? Talvez você faça o seu próprio e mantenha-os o menor possível. O mais provável é que você use componentes de terceiros (talvez open source licenciado pelo MIT) que tenham muitas funcionalidades de que você nunca precise, mas uma vez que você precise de uma única função de um componente de terceiros, você terá que carregar todo o componente. Então, você adiciona mais e 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 enorme quantidade de código compilado em excesso / biblioteca.

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

Exemplo de como o código grande pode ser por nenhuma razão óbvia: eu fiz uma saída de texto simples "Hello, World!" em Ada recentemente. O executável compilado tinha mais de 1 MiB !. O mesmo executável na montagem é apenas um KiB ou 2 (e a maior parte é a sobrecarga executável, o código atual em execução é de dezenas de bytes).

É trivialmente verdade que o software deve ser construído para encaixar duas coisas: os usuários e o hardware disponível. Um programa é adequado para o seu propósito se ele faz o que o usuário deseja em tempo hábil com o hardware à disposição do usuário. Bem duh. Mas à medida que o hardware melhora, basicamente, em todas as dimensões mensuráveis, o número de programas discretos que se deslocam de crescimentos impróprios para ajustáveis - o espaço de design fica maior:

• Idiomas de nível superior tornam possível expressar ideias em menos código & tempo do que antes. Essa menor complexidade, ao contrário, torna possível expressar ideias cada vez mais complexas.
• Agrupar mais dados com o aplicativo podem torná-lo instantaneamente mais utilizável. Por exemplo, provavelmente não demorará muito para que os aplicativos de verificação ortográfica sejam empacotados com todos os idiomas conhecidos pela humanidade - são apenas alguns gigabytes, afinal.
• Trocas de hardware permitem que desenvolvedores e usuários escolham mais sobre qual recurso eles se importam. Veja por exemplo FLAC / OGG vs WAV, SVG vs PNG, índices de banco de dados.
• Interfaces Humane frequentemente trocam o que anteriormente equivaleria a enormes quantidades de hardware para usabilidade. Anti-aliasing, altas resoluções, atualização rápida e deslizamento entre o que resulta em painéis discretos contribuem para uma experiência mais realista e, portanto, intuitiva e relacionável.

Isso é definitivamente verdade em relação aos aplicativos Android. Quatro anos atrás, um aplicativo simples ocupava cerca de 2 a 5 megabytes de espaço. 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.

Acho que há dois motivos 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 estão incluídas em uma resolução muito maior (é claro que as resoluções de tela do smartphone aumentaram), bibliotecas de terceiros estã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 entrava em cena, ele competia com o C / C ++ e o grande problema era que você poderia escrever 'Hello World' em ANSI C para Windows em talvez 15K. O problema com o VB é 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 assim seria apenas mais alguns K, mas 10x o tamanho do seu programa C / C ++ e você está observando alguns meses a mais de desenvolvimento.

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

Mas satisfazer uma nova necessidade significa frequentemente adicionar novo código. Novo código significa novas vulnerabilidades para corrigir. Corrigir novas vulnerabilidades pode adicionar código ou abrir portas para novas vulnerabilidades.

Cada recurso adicionado para satisfazer a necessidade do 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.

Grande parte vem de bibliotecas internas. Muitas aplicações hoje em dia são construídas com o uso de elétrons, o que agrega uma enorme quantia ao aplicativo. Se você instalar aplicativos no Linux, eles geralmente são muito menores, porque grande parte do aplicativo já está instalado por meio de bibliotecas compartilhadas que outros programas também estão usando.

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

Talvez não seja o mesmo caso, mas algo assim: Se você só precisar imprimir "hello world" no console usando Java, precisará do JRE (> 60MB) instalado.

Se o exemplo de Java não for bom, tente este: Se o software precisar registrar em log, ele pode usar um módulo de registro que pode realmente criar logs no banco de dados, pela rede e outros recursos, mas as funções são nunca usado no projeto.

I read about some rule that programs will take all available memory no matter how much it is but why?

Isso não é bem verdade. Os sistemas não liberam a memória consumida até que o sistema operacional fique sob pressão de memória. Esta é uma melhoria de desempenho. Se você estava navegando em uma página com imagens, você navega. Você pode navegar de volta, necessitando, portanto, da imagem novamente. Se o sistema operacional tiver a RAM, não há sentido em limpar a memória até ter certeza de que não precisará dela novamente.

Limpar a memória imediatamente retiraria os ciclos da CPU e a largura de banda da memória do usuário quando, provavelmente, eles estivessem provavelmente desejando que páginas da Web altamente responsivas fossem exibidas na tela.

O sistema operacional consumirá toda a memória disponível que não seja de aplicativos, a maioria dos quais é para o cache do sistema de arquivos.

O gerenciamento de memória é um problema difícil, mas há pessoas muito inteligentes trabalhando nisso o tempo todo. Nada está sendo desperdiçado de propósito e o objetivo principal é fornecer a você 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 pistas a uma superestrada sem saída e, em alguns anos, o tráfego é feito novamente.

Mas se você investigar, poderá descobrir que os programas realmente fazem mais coisas. Os navegadores, por exemplo, executam gráficos mais sofisticados, têm ferramentas engenhosas para desenvolvedores 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 motivos legítimos.

Bibliotecas construídas 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 sua maior parte inchado.

Basta percorrer o código C ++ padrão em execução para ver todas as chamadas do objeto assert () ed para garantir que sejam objetos válidos. Quando você cria camada sobre camada de objetos que encapsulam objetos, as camadas inferiores são inchadas e opacas. Os programadores ficam com preguiça e aceitam mais objetos porque é mais rápido do que redesenhar o que é limitado à funcionalidade necessária. É tão simples assim.

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