Perché le dimensioni dei programmi sono così grandi?

"Guardare in modo molto diverso" è una questione di percezione. La grafica di oggi deve guardare bene a risoluzioni dello schermo completamente diverse da quelle del passato, con il risultato che un'immagine 100x100 che prima era più che buona per un logo ora apparirebbe orribilmente appiccicosa. È stato necessario sostituirlo con un'immagine 1000x1000 della stessa cosa, che è un fattore 100 proprio lì. (So che è possibile utilizzare la grafica vettoriale, ma ciò sottolinea solo il punto: il codice di rendering della grafica vettoriale deve essere aggiunto a sistemi che non ne avevano bisogno prima, quindi questo è solo un compromesso rispetto a un tipo di aumento della dimensione a un altro.)

"Lavorare in modo diverso" è anche una questione di percezione. Il browser di oggi fa massivamente più cose di una dal 1995. (Prova a navigare in Internet con un laptop storico in un giorno di pioggia - scoprirai che è quasi inutilizzabile.) Non molti di questi sono usati molto, e gli usi potrebbero essere completamente inconsapevoli del 90% di essi, ma ci sono.

In cima a tutto ciò, naturalmente, c'è la tendenza generale a dedicare meno tempo all'ottimizzazione delle cose per lo spazio e altro all'introduzione di nuove funzionalità. Questo è un naturale effetto collaterale di computer più grandi, più veloci e più economici per tutti. Sì, sarebbe possibile scrivere programmi efficienti dal punto di vista delle risorse come lo erano nel 1990, e il risultato sarebbe incredibilmente veloce e fluido. Ma non sarebbe più redditizio; il tuo browser impiegherebbe dieci anni per essere completato, quindi i requisiti sarebbero completamente cambiati. Le persone erano solite programmare con estrema attenzione all'efficienza, perché le macchine lente e piccole li costringevano a fare le cose, e anche tutti gli altri lo facevano. Non appena questo è cambiato, il collo di bottiglia per il successo del programma è passato dall'essere in grado di eseguire affatto per eseguire più e più cose brillanti , ed è qui che ci troviamo adesso.

Se confronti Netscape Navigator con un browser moderno, c'è una differenza di funzionalità massiccia . Basta confrontare HTML 3.2 Spec (51 pagine quando eseguo un'anteprima di stampa) con Specifica HTML corrente (la versione PDF è 1155 pagine). Si tratta di un aumento delle dimensioni di 20 volte.

Netscape Navigator non aveva un DOM e non aveva CSS! Non ci sono state modifiche dinamiche del documento, nessun JavaScript che modifica il DOM oi fogli di stile. Nessun tab. Nessun audio o video. Un browser moderno è un programma ampiamente più complesso.

Una ragione è che i dati impacchettati all'interno delle applicazioni sono più grandi perché hanno una maggiore risoluzione e qualità. Un'icona ai tempi di Netscape era al massimo 32x32 pixel, con una profondità massima di 8 bit, (probabilmente solo 4), mentre ora è probabilmente qualcosa come 64x64 ed è a colori veri con trasparenza, ovvero a 32 bit di profondità. Questo è 16 volte più grande. E lo spazio è così economico che spesso le persone non si preoccupano nemmeno di controllare l'opzione "compressa" durante la generazione di un PNG.

Un altro motivo è che le applicazioni oggigiorno portano con sé una quantità incredibile di dati, che le applicazioni meno recenti non hanno. Oggi esistono applicazioni che vengono spedite insieme a una presentazione "iniziale" nel video .

Un altro motivo è che i linguaggi di programmazione oggi tendono ad andare insieme a ricchi ambienti di runtime, che sono abbastanza grandi, per un totale di 100 MB ciascuno. Anche se non utilizzi tutte le funzionalità del tuo ambiente run-time, devi comunque comprimere il tutto con la tua app.

Ma la ragione principale è che oggi esistono tonnellate e tonnellate di librerie che possiamo usare nelle nostre applicazioni, e abbiamo sviluppato una cultura dell'uso delle librerie per evitare la costante reinvenzione della ruota. Naturalmente, quando inizi a utilizzare le librerie, compaiono diverse domande e abbiamo sviluppato l'abitudine di dare loro le risposte più liberali:

• Vale la pena includere un'altra libreria se verrà utilizzata solo da una delle mie funzioni? -. Sì

• Vale la pena includere un'altra libreria se ho solo bisogno di un piccolo sottoinsieme dell'intera ricchezza di funzionalità offerta da quella libreria? -. Sì

• Vale la pena includere un'altra libreria se la sua inclusione mi salverà solo da 2 giorni di lavoro? -. Sì

• Vale la pena includere più librerie che servono più o meno allo stesso scopo solo perché diversi programmatori sul mio libro paga hanno già familiarità con diverse librerie? -. Sì

  (Si noti che sto solo osservando queste tendenze, non sto facendo alcuna dichiarazione sul fatto che io sia d'accordo o in disaccordo con loro.)

Un'altra ragione degna di nota è che quando si tenta di decidere quale applicazione usare tra diverse scelte, alcuni utenti pensano che quello che occupa più spazio sarà più ricco di funzionalità, avrà una grafica più elaborata, ecc. (Che è un'assurdità completa, ovviamente.)

Quindi, per concludere, il software si comporta come il gas? Tende a occupare tutto lo spazio a disposizione? In un certo senso sì, ma non in misura allarmante. Se guardiamo a ciò che occupa più spazio sui nostri dischi, per la maggior parte di noi la risposta è che non si tratta di applicazioni, ma di media come film e musica di gran lunga . Il software non è cresciuto alla stessa velocità con cui la capacità di archiviazione si è espansa ed è improbabile che lo sia mai, quindi in futuro le applicazioni probabilmente rappresenteranno una frazione trascurabile dello spazio di archiviazione disponibile per utenti.

In aggiunta agli altri anser, 10 anni fa in genere ci sarebbero state versioni separate per versioni localizzate / internazionalizzate. Ora, in genere, i programmi raggrupperanno il supporto completo per la localizzazione in ogni versione rilasciata che supporta le dimensioni del programma.

Una ragione sono le dipendenze. Un programma ricco di funzionalità e di bell'aspetto ha bisogno di molte cose: crittografia, controllo ortografico, lavoro con XML e JSON, modifica del testo e molte altre cose. Da dove vengono? Forse fai da te e mantienili il più piccolo possibile. Molto probabilmente utilizzi componenti di terze parti (forse open source con licenza MIT) che hanno molte funzionalità che non ti servono mai, ma una volta che hai bisogno di una singola funzione da un componente di terze parti, spesso devi trasportare l'intero componente. Quindi aggiungi sempre più dipendenze e man mano che si evolvono e cresce anche il tuo programma che dipende da loro.

Mentre la grafica / usabilità sono davvero fattori che contribuiscono, c'è un sacco di cose che sono librerie / codice compilato in eccesso.

Esempio di come il codice piccolo può ancora essere: MenuetOS, un sistema operativo a 64 bit con app potenti che si adattano a un singolo disco floppy.

Esempio di come il codice grande può essere senza una ragione ovvia: ho fatto un semplice output di testo "Hello, World!" Ada di recente. L'eseguibile compilato ha superato 1 MiB !. Lo stesso eseguibile in assembly è solo un KiB o 2 (e la maggior parte di esso è un overhead eseguibile, il codice corrente è di decine di byte).

È banalmente vero che il software deve essere costruito per adattarsi a due cose: gli utenti e l'hardware disponibile. Un programma è adatto al suo scopo se fa ciò che l'utente desidera in modo tempestivo con l'hardware a disposizione dell'utente. Bene. Ma poiché l'hardware migliora sostanzialmente in tutte le dimensioni misurabili, il numero di programmi discreti che passano da non idonei a incrementi aumenta - lo spazio di progettazione diventa più grande:

• Lingue di livello superiore consentono di esprimere idee in meno codice e amp; tempo di prima. Questa complessità ridotta, al contrario, consente di esprimere idee sempre più complesse.
• Raggruppare più dati con l'applicazione può renderlo immediatamente più utilizzabile. Ad esempio, probabilmente non passerà molto tempo prima che le applicazioni di controllo ortografico vengano fornite in bundle con tutte le lingue conosciute dall'umanità: dopo tutto sono solo pochi gigabyte.
• I compromessi sull'hardware consentono agli sviluppatori e agli utenti di scegliere più a fondo in quale risorsa interessano. Vedi ad esempio FLAC / OGG vs WAV, SVG vs PNG, indici di database.
• Interfacce umane spesso compromettono ciò che in precedenza equivaleva a enormi quantità di hardware per l'usabilità. L'anti-aliasing, le risoluzioni elevate, l'aggiornamento rapido e lo swiping tra ciò che equivale a pannelli discreti rendono tutti un'esperienza più realistica, e quindi intuitiva e riconoscibile.

Questo è sicuramente vero per le applicazioni Android. Quattro anni fa, una semplice app richiedeva circa 2-5 megabyte di spazio. Oggigiorno una semplice app richiede circa 10-20 megabyte di spazio.

Maggiore è lo spazio disponibile, maggiore è la dimensione dell'app.

Penso che ci siano due ragioni principali nel caso di Android:

• Google ha ampliato il framework Android, aggiunto molte nuove funzionalità.

• Gli sviluppatori non si preoccupano più. Le immagini sono incluse in una risoluzione molto più alta (ovviamente le risoluzioni dello schermo dello smartphone sono aumentate), le librerie di terze parti sono incluse senza pensieri.

Molti di questi si riducono al tempo di sviluppo e al costo di quel tempo. Ai tempi in cui Visual Basic arrivò per la prima volta sulla scena, era in competizione con C / C ++ e il grosso problema era che si poteva scrivere "Hello World" in ANSI C per Windows in forse 15K. Il problema con VB è che hai sempre avuto l'albatross della libreria di runtime 300K.

Ora, potevi 10 volte la dimensione del tuo programma VB e sarebbero ancora solo pochi K, ma 10 volte la dimensione del tuo programma C / C ++ e stai considerando alcuni MONTHS di ulteriore sviluppo.

Alla fine, il peso delle tue applicazioni è un piccolo prezzo da pagare per gli enormi balzi in avanti nella produzione di sviluppo, nella riduzione dei prezzi e nella vastità delle capacità che non sarebbero mai state possibili nei vecchi giorni di sviluppo fatti a mano; quando i programmi erano piccoli e veloci ma anche deboli, incompatibili tra loro, sottocompletati e costosi da sviluppare.

Di volta in volta, le esigenze degli utenti sono in continua evoluzione e sempre più esigenti, così i venditori / autori di diversi software sono costretti a soddisfare tali esigenze in nome della concorrenza.

Ma soddisfare una nuova esigenza significa spesso aggiungere un nuovo codice. Nuovo codice significa nuove vulnerabilità da risolvere. La correzione di nuove vulnerabilità può aggiungere codice o aprire porte a nuove vulnerabilità.

Ogni funzionalità aggiunta per soddisfare le esigenze di un utente potrebbe richiedere più potenza del processore per la velocità (ci lamentiamo tutti della velocità di questo o quel browser), nuove risorse grafiche per migliori effetti visivi ... ecc.

Tutto ciò significa aggiungere nuovi livelli di applicazioni (codice), sicurezza e talvolta hardware.

Molte delle dimensioni provengono da librerie incorporate. Molte applicazioni al giorno d'oggi sono costruite usando l'elettrone che raggruppa una quantità enorme con l'applicazione. Se installi applicazioni su Linux, di solito sono molto più piccole perché gran parte dell'applicazione è già installata tramite librerie condivise che vengono utilizzate anche da altri programmi.

Quando costruisci il software, se hai bisogno della funzione A, dovrai importare un modulo A *. A * può risolvere A, ma A * può risolvere problemi più di A e A * potrebbe essere grande. Tutti i moduli di grandi dimensioni risultano nel software di grandi dimensioni.

Forse non è lo stesso caso, ma qualcosa del genere: se hai solo bisogno di stampare "Hello World" su console usando Java, hai bisogno di JRE (> 60MB) installato.

Se l'esempio di Java non è buono, prova questo: se il software ha bisogno di accedere al file, può utilizzare un modulo di registrazione che può effettivamente effettuare i log sul database, sulla rete e alcune altre funzionalità, ma le funzioni sono mai usato nel progetto.

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

Non è proprio vero. I sistemi non rilasceranno la memoria che hanno consumato fino a quando il sistema operativo non sarà sotto pressione di memoria. Questo è un miglioramento delle prestazioni. Se stai navigando in una pagina con le immagini attivate, ti allontani. Potresti tornare indietro, quindi hai bisogno nuovamente dell'immagine. Se il sistema operativo ha la RAM, non è necessario svuotare la memoria finché non si è sicuri di non averne più bisogno.

L'eliminazione immediata della memoria richiederebbe ai cicli della CPU e alla larghezza di banda della memoria di allontanarsi dall'utilizzatore quando probabilmente è probabile che vogliano visualizzare sullo schermo pagine Web altamente reattive.

Il sistema operativo consumerà tutta la memoria non dell'applicazione disponibile, la maggior parte delle quali è per la cache del file system.

La gestione della memoria è un problema difficile, ma ci sono persone molto intelligenti che ci lavorano tutto il tempo. Niente viene sprecato di proposito e l'obiettivo principale è quello di fornire un computer molto reattivo.

Può essere vero che i programmi tendono ad espandersi per riempire lo spazio disponibile, in modo simile ai fenomeni suburbani in cui aggiungi nuove corsie a una superstrada a griglia e in pochi anni il traffico viene nuovamente eseguito.

Ma se ci guardi dentro potresti scoprire che i programmi in realtà fanno più cose. I browser, ad esempio, eseguono grafici fantasiosi, hanno strumenti di sviluppo chiari che non esistevano alcuni anni fa, ecc. Inoltre collegano molte librerie, a volte usando solo una piccola parte del codice. Quindi, mentre i programmi possono aumentare di dimensioni per riempire la memoria disponibile, alcuni di questi potrebbero essere motivi legittimi precedenti.

Le librerie create su oggetti che non sono ottimizzati richiedono più memoria da caricare, installare e più cicli di calcolo per funzionare. Il codice oggetto è per la maggior parte gonfio.

È sufficiente scorrere il codice C ++ standard in esecuzione per visualizzare tutte le chiamate di assert () ed object per assicurarsi che siano oggetti validi. Quando disegni strati su strati di oggetti che incapsulano oggetti, i sottostrati sono gonfiati e opachi. I programmatori diventano pigri e assumono più oggetti perché è più veloce della riprogettazione di ciò che è limitato alle funzionalità necessarie. È davvero così semplice.

Considerare le dimensioni del kernel Linux C, solo il kernel, rispetto alle dimensioni delle applicazioni personalizzate. Il kernel può eseguire l'intera macchina. Ma non è stato creato con la stessa rapidità delle applicazioni, richiede molto tempo per ottenere la migliore funzionalità.