Quando un EXE o una DLL riutilizzano la memoria "fisica"?

Negli anni la mia applicazione è passata da pochi MB a oltre 50 MB. Per semplificare l'implementazione, mi sono sempre limitato ad avere un singolo file EXE invece di avere un EXE più piccolo e un sacco di DLL (vedi anche la mia domanda su StackOverflow: https://stackoverflow.com/questions/2881296/one-big-executable-or-many-small-dlls ).

Tuttavia, ora ho alcuni clienti che si lamentano che ogni nuova versione ha requisiti di memoria più elevati. Passare alle DLL potrebbe risolvere alcuni di questi problemi, perché penso che Windows carichi solo le DLL una volta in memoria (quindi se si hanno 50 processi tutti usando la stessa DLL, la DLL occupa spazio solo una volta nella memoria fisica).

D'altra parte, se ho 50 processi tutti usando lo stesso file EXE, mi aspetto che Windows condivida anche questo file EXE per più processi. Ma ho l'impressione che Windows non lo faccia (e lo fa solo per i file DLL). Questa osservazione è vera?

Windows carica veramente una DLL una volta in memoria se utilizzata da più processi?

Windows carica anche un file EXE una volta in memoria se utilizzato da più processi? O no?

Innanzitutto, i metodi DLL e i costrutti statici fanno parte dell'impronta dello stack del processo e pertanto la loro memoria non viene allocata dinamicamente, quindi rompere le cose con le DLL aggiuntive non ridurrà i requisiti effettivi del ram.

La memoria di processo può essere misurata usando il Byte privati (l'intero footprint di memoria del processo, meno eventuali oggetti condivisi, potrebbe non riflettere l'utilizzo fisico del ram) working set bytes (memoria fisica corrente in uso, oltre a oggetti condivisi) e set di lavoro privato (piena memoria fisica in uso, senza oggetti condivisi). Tutti questi possono essere monitorati in ProcessExplorer di Sysinternal. WS Private è probabilmente la migliore metrica per monitorare la quantità di carico che il programma colloca sull'host.

Il codice DLL e EXE è assolutamente condiviso: c'è solo una copia del codice nella RAM, indipendentemente dal numero di processi che utilizzano l'EXE o le DLL. (ANd, non tutto il codice sarà necessariamente nella RAM, solo quello a cui è stato fatto riferimento di recente).

DLL ed EXE sono esempi di file mappati. I file mappati contribuiscono allo spazio di indirizzamento virtuale totale di un processo. Non contribuiscono alla memoria "privata" o "impegnata" (stessa cosa, ma le diverse utilità utilizzano termini diversi).

I processi no di per sé , avere pile. I thread hanno stack. (Si potrebbe dire che un processo con un solo thread ha uno stack "a" per quel processo, ma in realtà, lo stack è un attributo del thread, non del processo.) Ma le DLL non sono "caricate in uno stack di processi" ( né in una pila di thread per quella materia). DLL e EXE sono mappati nello spazio di indirizzi virtuale condivisibile - non privato - di un processo. È vero che questo viene fatto per ogni processo usando la DLL o l'EXE, ma queste istanze multiple sono per i mapping della memoria virtuale. Poiché questo è spazio di indirizzamento virtuale condivisibile, c'è ancora solo una copia del codice nella RAM.

Stack di thread, insieme a heap (che siamo a livello di processo) e l'archiviazione statica, sono anche mappati nel processo v.a.s., ma a differenza della memoria mappata, sono privati ​​di ogni processo.