Il tempo di esecuzione del programma è influenzato dalla dimensione del file?

4

Dire che ho scritto un programma contenente 3 metodi. Ogni metodo era 100 linee. Il metodo 1 era main () e il metodo 2 era chiamato da main ().

Ho quindi duplicato il programma in un secondo programma identico. Dopo averlo duplicato, ho aggiunto 4900 linee al Metodo 3.

Il metodo 3 non viene mai chiamato da nessuno dei due programmi.

Il programma 1 ha una dimensione del file di 3,7kb. Il programma 2 ha una dimensione del file di 62,5 KB.

Questo cambiamento nelle dimensioni del file influenzerà il tempo di esecuzione del programma, anche se il metodo 3 non è mai stato chiamato? Cosa succede se il metodo 3 ha aggiunto delle righe fino a quando il Programma 2 ha raggiunto la dimensione estrema?

Questo effetto nel tempo di esecuzione dovrebbe essere considerato fino al livello di nanosecondo, poiché questo è un effetto non trascurabile in alcune situazioni. Inoltre, vorrei considerare questo effetto sia per le lingue compilate che per quelle interpretate.

(Questo è facile da testare per qualcosa di piccolo come 300 v 5200 linee. Sto chiedendo più circa l'aspetto teorico della dimensione del file che incidono sul tempo di esecuzione di uno scenario specifico.)

La mia domanda è stata contrassegnata come un duplicato di La micro-ottimizzazione è importante per la codifica ? . Queste domande non hanno alcuna relazione, poiché non sto chiedendo se la micro-ottimizzazione è importante o non importante. Sto chiedendo se la dimensione del file ha un effetto sul tempo di esecuzione del programma. Non mi interessa se l'effetto che ha è importante o non importante, mi interessa solo che l'effetto esiste o non esiste. Anche l'altra domanda non menziona in modo specifico l'effetto della dimensione del file su un programma - la loro domanda si concentra più sulla struttura logica di un programma piuttosto che sulla dimensione del file del programma.

    
posta Logan Hartman 21.08.2016 - 03:14
fonte

4 risposte

11

In teoria, la dimensione del file sì può influenzare il tempo di esecuzione di un programma. Tuttavia, l'effetto che ha è probabilmente così insignificante che non dovresti mai preoccuparti di questo.

Ci sono alcuni motivi per questo:

  1. I compilatori / interpreti sono molto intelligenti e ottimizzeranno il codice per essere il più performante possibile. Il tuo esempio sarebbe un ottimo candidato per eliminazione del codice morto . Tuttavia, non sono perfetti, quindi esiste la possibilità che variabili inutilizzate, codice non raggiungibile, ecc. Possano influenzare l'output (istruzioni della CPU) del compilatore / interprete. In poche parole, il modo in cui scrivi codice può influenzare le istruzioni della CPU in uscita. Vedere il link del post del blog qui sotto per un esempio reale di questo.

  2. Come conseguenza della "dimensione del file" che influenza le istruzioni della CPU, i dati nel programma potrebbero estendersi in un modo che influisce sulle prestazioni. La località di riferimento spiega molto di questo. In breve, le località povere causano problemi come la mancanza di cache e il thrashing.

  3. Anche se non influisce necessariamente sul runtime, una dimensione di file più grande richiede più tempo per caricare dal disco e più a lungo per interpretare (per le lingue interpretate), influenzando l'avvio del programma.

  4. Se il tuo programma era abbastanza grande, potrebbe causare un errore di pagina .

Per ulteriori dettagli, questo post del blog entra in molti dettagli di come la riduzione della dimensione binaria ha aiutato le prestazioni.

Detto questo, la "dimensione del file" è qualcosa che non dovresti preoccuparti di circa il 99% delle situazioni.

    
risposta data 21.08.2016 - 04:56
fonte
2

La maggior parte dei sistemi operativi moderni userà le funzionalità memoria virtuale (supportate da funzionalità hardware) nella memoria per mappare il file eseguibile in memoria , il che suggerisce che ci sarà poco o nessun effetto a causa delle dimensioni del file eseguibile, se il contenuto è in gran parte inutilizzato / non referenziato.

La memoria virtuale, combinata con la copia su scrittura, funziona anche su dati di lettura / scrittura unici per il particolare processo istanziato; copy-on-write rileva (inizialmente il file) le pagine mappate che vengono modificate e, in genere, la memoria virtuale spinge le pagine dirty (modificate) verso paging file come necessario quando si ha a che fare con i vincoli di memoria.

Ok, calcolando il tempo di caricamento, supponiamo per i principianti che il contenuto di file inutilizzato extra che stai chiedendo si verifichi dopo tutto il codice che effettivamente si abitua, che è raggruppato insieme all'inizio. Non ci dovrebbero essere praticamente effetti sulle prestazioni di runtime per questo. In generale, ad eccezione della cache della CPU, la stessa sequenza di istruzioni eseguita richiederà lo stesso tempo.

Ci sono comportamenti specifici della cache che potrebbero darti un singhiozzo o anche alcuni comportamenti patologici, ma in realtà non vedo grossi problemi associati a una grossa porzione contigua di codice o dati a cui non viene fatto riferimento in alcun modo.

Per essere più chiari, le cache hardware hanno una nozione di associatività. Su processori moderni che di solito sono a 8 o più vie. Embedded potrebbe variare. Quale associatività della cache hardware di N-way, è consentito fino a N indirizzi con hash allo stesso valore (un hash interno alla cpu di indirizzi) da memorizzare nella cache. Ora, quando provi a memorizzare nella cache un N + 1th valore che si verifica nello stesso hash, uno degli altri elementi viene rimosso, anche se nella cache rimangono ancora i kilobyte rimasti inutilizzati. Le cache hardware sono progettate per funzionare molto bene con la memoria contigua.

Quindi, se si inserisce altra memoria che non viene utilizzata tra la memoria utilizzata, è possibile creare un caso patologico in cui non si utilizza effettivamente la cache a causa di un limite di associatività. Dovresti provare piuttosto: inserendo tutto il tuo codice effettivamente acceduto (& data) sullo stesso hash della linea cache, potresti esaurire l'associatività. Ricorda che una parte di questo (a corto di associatività) si verifica anche in circostanze normali, quindi direi che, a parte il tentativo di costruire un caso peggiore, questo non dovrebbe essere un fattore anche per uno o più grumi di codice o di dati caricati ma non altrimenti usato.

Ora, c'è ancora un altro effetto, ovvero che le cache sono segmentate in linee, che sono blocchi di, ad esempio 128, 256 o 512 bit (o altro). In un altro caso patologico, è possibile utilizzare la cache in un modo diverso. Poiché la cache (quasi, in base alla CPU) carica una riga di cache completa anche quando è necessario un solo byte, è possibile creare uno scenario in cui la cache viene esaurita più rapidamente di quanto ci si aspetterebbe, utilizzando solo una quantità molto piccola di memoria effettiva per linea della cache. Come con l'altro caso, dovresti lavorare sodo per costruire un caso patologico, ma l'idea è quella di interspondere il codice (oi dati) che viene usato con il codice oi dati che non vengono usati in determinati intervalli molto regolari.

(C'è un effetto simile sul paging della memoria virtuale, che puoi utilizzare la memoria reale più velocemente di quanto desideri usando solo un piccolo numero di byte per pagina.)

Salvo qualche costruzione patologica progettata per danneggiare la cache, codice o dati in più inutilizzati non dovrebbero influire sulle prestazioni del runtime.

    
risposta data 21.08.2016 - 07:16
fonte
0

Se il codice è firmato , l'O / S dovrà caricare l'intera immagine del file, eseguire la scansione di ogni singolo byte e calcola una firma digitale. Il tempo richiesto per eseguire questa operazione ovviamente si ridimensionerà con la dimensione di .exe, indipendentemente da quanto sia effettivamente eseguito.

    
risposta data 23.08.2016 - 02:38
fonte
-1

Sì ... il tempo di esecuzione verrà influenzato nelle lingue (come JavaScript o lang interpretati). In caso di lang compilato. Come C o Java in esecuzione sarà interessato, ma in quantità molto inferiore (come nano o micro sec) Perché il compilatore deve caricare tutte le funzioni nella memoria principale in modo da controllare l'eventuale errore.

    
risposta data 21.08.2016 - 21:53
fonte

Leggi altre domande sui tag