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.