2010-10-05 8 views
6

Diciamo che ho un progetto con una dozzina di diversi moduli che producono una DLL risultante, come posso analizzarlo in modo che possa identificare la dimensione del file effettivo che ogni modulo/funzione contribuisce? So che potrebbe essere impossibile con una versione di Release in cui molte informazioni sono state rimosse, ma che ne dici se ho l'intera fonte e posso fare una compilazione di debug?Analizzare i file .exe/.dll (Windows PE) per il codice bloats

Inoltre, se ci sono le variabili statiche grandi definite da qualche parte, c'è un modo che posso facilmente trovare?

Domanda bonus: Che ne dici di file ELF di Linux?

+0

dumpbin dovrebbe IMHO mostrare grandi globale/statica. – valdo

+0

@valdo qualsiasi dettaglio su come farlo? Ho esplorato un po 'e non riuscivo a capirlo. – kizzx2

risposta

4

Ogni volta che sono stato coinvolto nell'identificazione gonfiare io generalmente inizio con dumpbin su Windows. Solitamente scrivendo uno strumento per esaminare ciascun modulo di oggetto tramite dumpbin, quindi analizzare l'output. Tende ad essere un processo iterativo e può richiedere una buona quantità di tempo.

Per build di debug con PDB Sizer in grado di produrre report utili.

Adrian ha alcune indicazioni utili qui. Minimizing Code Bloat for Faster Builds and Smaller Executables e uno strumento chiamato SymbolSort per aiutare. La sorgente in C# è inclusa in SymbolSort, quindi potrebbe essere un buon punto di partenza se SymbolSort non è di aiuto.

Per ELF l'output di nm e objdump rappresenta un buon punto di partenza.

+0

Questo è assolutamente fantastico! Hanno questa politica stupida di 24 ore per taglie: P – kizzx2

+0

appena preso uno sguardo al 'nm -s'. Che semplice problema che è così oscuro da risolvere su Windows: P – kizzx2