Perché le dimensioni dei programmi sono così grandi?

Se guardiamo il programma vintage Netscape Navigator o una versione precedente di Microsoft Word, quei programmi avevano dimensioni inferiori a 50 MB. Ora quando installo google chrome sono 200 MB e la versione desktop di Slack è 300 MB. Ho letto di alcune regole secondo cui i programmi occuperanno tutta la memoria disponibile, non importa quanto sia, ma perché?

Perché le dimensioni attuali dei programmi sono così grandi rispetto a 10 o 15 anni fa? I programmi non svolgono molte più funzioni e non sembrano molto diversi. Che cos'è ora il porco di risorse?

"L'aspetto molto diverso" è una questione di percezione. La grafica di oggi deve avere un bell'aspetto con risoluzioni dello schermo totalmente diverse rispetto a una volta, con il risultato che un'immagine 100x100 che era più che buona per un logo ora apparirebbe orribilmente di cattivo gusto. Ha dovuto essere sostituito con un'immagine 1000x1000 della stessa cosa, che è un fattore 100 proprio lì. (So ​​che invece puoi usare la grafica vettoriale, ma questo sottolinea solo il punto: il codice di rendering della grafica vettoriale ha dovuto essere aggiunto a sistemi che non ne avevano bisogno prima, quindi questo è solo un compromesso da un tipo di aumento delle dimensioni ad un altro.)

"Lavorare diversamente" è anche una questione di percezione. Il browser di oggi fa molto più di uno rispetto al 1995. (Prova a navigare in Internet con un laptop storico un giorno di pioggia - scoprirai che è quasi inutilizzabile.) Non molti di loro sono usati molto e gli usi potrebbero non essere completamente consapevoli di 90 % di loro, ma sono lì.

Oltre a ciò, naturalmente, c'è la tendenza generale a dedicare meno tempo all'ottimizzazione delle cose per lo spazio e più all'introduzione di nuove funzionalità. Questo è un effetto collaterale naturale di computer più grandi, più veloci ed economici per tutti. Sì, sarebbe possibile scrivere programmi efficienti in termini di risorse come nel 1990 e il risultato sarebbe incredibilmente veloce e fluido. Ma non sarebbe più conveniente; il completamento del browser richiederebbe dieci anni, entro i quali i requisiti sarebbero completamente cambiati. Le persone erano solite programmare con estrema attenzione all'efficienza perché le macchine lente e piccole di un tempo le costringevano a farlo, e lo facevano anche tutti gli altri. Non appena questo è cambiato, il collo di bottiglia per il successo del programma è passato dalla possibilità di correre alla corsasempre più cose luccicanti , ed è qui che siamo ora.

Se si confronta Netscape Navigator con un browser moderno, c'è una differenza enorme nella funzionalità. Basta confrontare le specifiche HTML 3.2 (51 pagine quando faccio un'anteprima di stampa) con le specifiche HTML correnti (la versione PDF è 1155 pagine). Questo è un aumento di 20 volte in termini di dimensioni.

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

Uno dei motivi è che i dati impacchettati all'interno delle applicazioni sono più grandi perché hanno una risoluzione e qualità più elevate. Un'icona ai tempi di Netscape era al massimo di 32x32 pixel, con una profondità massima di 8 bit, (probabilmente solo 4,) mentre ora è probabilmente qualcosa come 64x64 ed è in vero colore con trasparenza, che significa profondità a 32 bit. È 16 volte più grande. E lo spazio è così economico che le persone spesso non si preoccupano nemmeno di controllare l'opzione "compressa" quando si genera un PNG.

Un altro motivo è che le applicazioni oggigiorno portano con sé una quantità sbalorditiva di dati, cosa che le applicazioni meno recenti non avevano. Esistono oggi applicazioni che vengono spedite insieme a una presentazione "introduttiva" in video .

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

Ma il motivo principale è che oggi esistono tonnellate e tonnellate di librerie là fuori che possiamo usare nelle nostre applicazioni, e abbiamo sviluppato una cultura di utilizzo delle librerie per evitare la costante reinvenzione della ruota. Naturalmente, una volta che inizi a utilizzare le librerie, vengono visualizzate diverse domande e abbiamo sviluppato l'abitudine di fornire loro le risposte più liberali:

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

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

• Vale la pena di 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 nel mio libro paga hanno già familiarità con librerie diverse? - Sì.

  (Nota che sto solo osservando queste tendenze, non sto affermando in alcun modo se sono d'accordo o in disaccordo con esse.)

Un altro motivo degno di nota è che quando si tenta di decidere quale applicazione utilizzare tra diverse scelte, alcuni utenti pensano che quella che occupa più spazio sarà più ricca di funzionalità, avrà una grafica più elaborata, ecc. (Che è un'assurdità completa, ovviamente .)

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

Oltre alle altre risposte, 10 anni fa in genere ci sarebbero state versioni separate per le versioni localizzate / internazionalizzate. Ora è generalmente il caso che i programmi raggruppino il supporto completo per la localizzazione in ogni versione rilasciata che rispecchi le dimensioni del programma.

Uno dei motivi sono le dipendenze. Un programma con funzionalità avanzate e un bell'aspetto richiede molte cose: crittografia, controllo ortografico, utilizzo di XML e JSON, modifica del testo e molte altre cose. Da dove verrebbero? Forse arrotoli il tuo e tienilo il più piccolo possibile. Molto probabilmente usi componenti di terze parti (forse open source con licenza MIT) che hanno molte funzionalità che in realtà non ti servono mai, ma una volta che hai bisogno di una singola funzione da un componente di terze parti devi spesso portare in giro l'intero componente. Quindi aggiungi sempre più dipendenze e man mano che si evolvono e crescono il tuo programma dipende anche da loro.

Mentre la grafica / usabilità sono davvero fattori che contribuiscono, ce n'è moltissimo che è libreria / codice compilato in eccesso.

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

Esempio di quanto può essere grande il codice senza una ragione ovvia: ho fatto un semplice output di testo "Ciao, mondo!" di recente in Ada. L'eseguibile compilato era oltre 1 MiB !. Lo stesso eseguibile nell'assembly è solo un KiB o 2 (e la maggior parte di questo è un overhead eseguibile, il codice corrente in esecuzione è 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 sua disposizione. Bene duh. Ma poiché l'hardware migliora sostanzialmente in tutte le dimensioni misurabili, aumenta il numero di programmi discreti che si spostano da inadatti a adattarsi - lo spazio di progettazione aumenta:

• Lingue di livello superiore consentono di esprimere idee in meno tempo e codice rispetto a prima. Questa complessità ridotta, al contrario, consente di esprimere idee sempre più complesse.
• Il raggruppamento di 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 raggruppate in tutte le lingue conosciute dall'umanità - dopo tutto sono solo pochi gigabyte.
• I compromessi hardware consentono agli sviluppatori e agli utenti una scelta più ampia in quale risorsa si preoccupano. Vedere ad esempio FLAC / OGG vs WAV, SVG vs PNG, indici del database.
• Le interfacce umane spesso scambiano ciò che in precedenza equivaleva a enormi quantità di hardware per usabilità. L'antialiasing, le risoluzioni elevate, l'aggiornamento rapido e lo scorrimento tra elementi equivalenti a pannelli discreti rendono l'esperienza più realistica, quindi intuitiva e comprensibile.

Questo è sicuramente vero per quanto riguarda le applicazioni Android. Quattro anni fa, una semplice app occupava circa 2-5 megabyte di spazio. Oggi una semplice app occupa 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à.

• Agli sviluppatori non importa più. Le immagini sono incluse in una risoluzione molto più elevata (ovviamente le risoluzioni dello schermo dello smartphone sono aumentate), le librerie di terze parti sono incluse senza pensarci.

Molto si riduce al tempo degli sviluppatori e al costo di quel tempo. Ai tempi in cui Visual Basic era arrivato per la prima volta sulla scena, era in competizione con C / C ++ e il grande colpo era che si poteva scrivere "Hello World" in ANSI C per Windows in forse 15K. Il problema con VB era che hai sempre avuto l'albatro della libreria di runtime 300K.

Ora, potresti 10 volte la dimensione del tuo programma VB e sarebbe ancora solo qualche K in più, ma 10 volte la dimensione del tuo programma C / C ++ e stai osservando qualche MESE in più di sviluppo.

Alla fine il gonfio delle tue applicazioni è un piccolo prezzo da pagare per gli enormi balzi nella produzione di sviluppo, la riduzione dei prezzi e la vastità delle capacità che non sarebbero mai state possibili nei vecchi tempi di sviluppo fatti a mano; quando i programmi erano piccoli e veloci ma anche deboli, incompatibili l'uno con l'altro, scarsamente caratterizzati e costosi da sviluppare.

Con il passare del tempo, le esigenze degli utenti sono in evoluzione e sempre più esigenti, quindi i fornitori / autori di software diversi sono costretti a soddisfare tali esigenze in nome della concorrenza.

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

Ogni funzionalità aggiunta per soddisfare le esigenze di un utente potrebbe richiedere una maggiore 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 dimensioni provengono da librerie integrate. Molte applicazioni in questi giorni sono costruite utilizzando elettroni che raggruppano moltissimo 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 stanno utilizzando anche altri programmi.

Durante la costruzione del software, se è necessaria la funzione A, verrà importato 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 producono software di grandi dimensioni.

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

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

Ho letto di alcune regole secondo cui i programmi occuperanno tutta la memoria disponibile, non importa quanto sia, ma perché?

Non è del tutto vero. I sistemi non rilasceranno la memoria che hanno consumato fino a quando il sistema operativo non sarà sottoposto alla pressione della memoria. Questo è un miglioramento delle prestazioni. Se stavi sfogliando una pagina con immagini attive, vai via. Potresti tornare indietro, quindi hai di nuovo bisogno dell'immagine. Se il sistema operativo ha la RAM non ha senso svuotare la memoria fino a quando non si è sicuri di non averne più bisogno.

La cancellazione immediata della memoria porterebbe i cicli della CPU e la larghezza di banda della memoria lontano dall'utente quando probabilmente molto probabilmente vogliono che le pagine Web altamente reattive vengano visualizzate sullo schermo.

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

La gestione della memoria è un problema difficile ma ci sono persone molto intelligenti che ci lavorano continuamente. Nulla 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 si aggiungono nuove corsie a una superstrada bloccata dalla griglia e nel giro di pochi anni viene nuovamente eseguito il backup del traffico.

Ma se lo guardi potresti scoprire che in realtà i loro programmi fanno più cose. I browser, ad esempio, eseguono grafica più elaborata, dispongono di strumenti di sviluppo intuitivi che non esistevano alcuni anni fa, ecc. Inoltre si collegano a molte librerie, a volte utilizzando solo una piccola parte del codice. Pertanto, sebbene i programmi possano aumentare di dimensioni per riempire la memoria disponibile, alcuni di questi potrebbero essere motivi legittimi.

Le librerie basate su oggetti non ottimizzati richiedono più memoria per caricare, installare e più cicli di elaborazione per funzionare. Il codice oggetto è per lo più gonfio.

Basta scorrere il codice C ++ standard in esecuzione per vedere tutte le chiamate agli oggetti assert () ed per assicurarsi che siano oggetti validi. Quando si progetta strato su strato 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 alla funzionalità necessaria. È davvero così semplice.

Considera la dimensione del kernel C Linux, solo il kernel, rispetto alla dimensione delle applicazioni su misura. Il kernel può eseguire l'intero computer. Ma non è stato creato così rapidamente come le applicazioni, ci vuole tempo lentamente per rendere la migliore funzionalità.