Quali sono le conseguenze negative di includere e / o il collegamento cose che non vengono utilizzati dal vostro binario?

Question

Diciamo che ho un binario che sto costruendo, e includo un gruppo di file che non sono mai effettivamente utilizzati, e fare il successivo collegamento alle librerie descritti da coloro include i file? (Ancora una volta, queste librerie non vengono mai utilizzati)

Quali sono le conseguenze negative di questo, al di là di aumento del tempo di compilazione?

Answer 1

Alcuni mi vengono in mente sono l'inquinamento dello spazio dei nomi e dimensioni binario

Answer 2

In aggiunta al tempo di compilazione; Maggiore complessità, distrazione inutile mentre debugging, un overhead di manutenzione.

A parte questo, nulla.

Answer 3

In aggiunta a quanto Sasha elenca è costi di manutenzione . Sarai in grado di rilevare facilmente quello che viene utilizzato e ciò che non viene utilizzato in futuro, quando e se si è scelto di rimuovere roba inutilizzata?

Answer 4

Se le librerie non sono mai utilizzati, non ci dovrebbe essere alcun aumento delle dimensioni per l'eseguibile.

Answer 5

A seconda del linker esatto, si potrebbe anche notare che gli oggetti globali delle vostre librerie inutilizzate ancora vengono costruite. Questo implica un sovraccarico della memoria e aumenta i costi di avvio.

Answer 6

Se le librerie che avete incluso, ma non utilizzano non sono sul sistema di destinazione, non sarà in grado di compilare anche se non sono necessari.

Answer 7

Qui è la mia risposta per una domanda analoga riguardante C e librerie statiche. Forse è utile a voi nel contesto di C ++ pure.

Answer 8

Si parla di un aumento del tempo di compilazione. Da che ho capito le librerie sono staticamente collegati, e non in modo dinamico. In questo caso, dipende da come il linker gestisce le funzioni non utilizzate. Se li ignora, si avrà per lo più problemi di manutenzione. Se essi saranno inclusi, la dimensione del file eseguibile aumenterà. Ora, questo è più significativo di quanto il posto che ci vuole sul disco rigido. Grandi eseguibili potevano correre più lento a causa di problemi di memorizzazione nella cache. Se il codice attivo e il codice non attivo sono adiacenti nel exe, essi verranno memorizzate insieme, rendendo la cache efficace più piccolo e meno efficiente.

VC2005 e sopra hanno un'ottimizzazione chiamato PGO, che ordina il codice all'interno del file eseguibile in modo da assicurare efficace cache di codice che viene spesso utilizzato. Non so se g ++ ha un'ottimizzazione simile, ma vale la pena guardare in quello.

Answer 9

Un po 'di compilazione qui di questioni, wiki-edit, se necessario:

Il problema principale sembra essere: Spazio dei nomi Inquinamento Questo può causare problemi in futuro il debug, il controllo di versione, e aumento futuro i costi di manutenzione.

Ci sarà anche, come minimo, minore Binary Bloat , come i riferimenti funzione / classe / namespace saranno mantenuti (Nella tabella dei simboli?). librerie dinamiche non dovrebbero aumentare notevolmente le dimensioni del binario (ma diventano una dipendenza per il binario per eseguire?). A giudicare dal compilatore GNU C, librerie collegate staticamente non devono essere inclusi in binario finale se sono mai riferimento alla fonte. (Assunzione basato sul compilatore C, potrebbe essere necessario chiarire / corretto)

Inoltre, a seconda della natura delle vostre librerie, oggetti globali e statici / variabili possono essere istanziati, causando aumentato il tempo di avvio e di sovraccarico di memoria .

Oh, e aumento / tempo di collegamento di compilazione.

Answer 10

Lo trovo frustrante quando posso modificare un file nella struttura di origine perché alcuni simbolo che sto lavorando su compare nel file di origine (ad esempio, un nome di funzione, dove ho appena cambiato il prototipo - o, purtroppo, ma più in genere, appena aggiunto il prototipo per un colpo di testa), quindi ho bisogno di controllare che l'utilizzo è corretto, o il compilatore ora mi dice che l'uso in quel file non è corretto. Quindi, posso modificare il file. Poi vedo un problema - quello che sta facendo questo file? E si scopre che anche se il codice è 'usato' nel prodotto, in realtà non viene utilizzato attivamente a tutti.

Ho trovato un evento di questo problema il Lunedi. Un file con 10.000 linee di codice invocata una funzione 'extern add_remainder void (void);' con un argomento di 0. Quindi, sono andato a risolvere il problema. Poi ho guardato il resto del codice ... si è scoperto che era un mozzicone di sviluppo da circa 15 anni fa, che non era mai stato rimosso. In modo pulito ablazione del codice si è rivelato per coinvolgere le modifiche minori a più di una mezza dozzina di file - e non ho ancora risolto se è possibile rimuovere la costante di enumerazione a partire dalla metà di un censimento nel caso. Temporaneamente, che è contrassegnato. 'Inutilizzato / obsoleto -? Può essere rimosso in sicurezza'

Questo pezzo di codice ha avuto una copertura pari a zero cala per gli ultimi 15 anni - produzione, collaudo, ... vero, è solo una piccola parte di un vasto sistema - percentuale-saggio, è meno di un blip 1% sul grafico. Eppure, è il codice sprecato in più.

sconcertante. Fastidioso. Depressingly comune (Ho effettuato l'accesso, e fissato, almeno una mezza dozzina di bug simili quest'anno finora).

E uno spreco del mio tempo - e il tempo di altri sviluppatori. Il file è stato modificato periodicamente nel corso degli anni da altre persone a fare quello che stavo facendo -. Un lavoro approfondito

Answer 11

Non ho mai avuto problemi con il collegamento di un file LIB della quale viene utilizzata solo una parte molto piccola. Solo il codice che viene realmente utilizzato sarà collegato nell'eseguibile, e il tempo di collegamento non è aumentato sensibilmente (con Visual Studio).

Answer 12

Se si collega a binari e ottengono caricati in fase di esecuzione, possono eseguire l'inizializzazione non banale che può fare qualsiasi cosa, da allocare una piccola quantità di memoria di consumare scarse risorse per alterare lo stato del modulo in modi che non si si aspettano, e non solo.

È meglio sbarazzarsi di roba che non è necessario, è sufficiente per eliminare una serie di incognite.

Answer 13

Si potrebbe forse anche non riuscire a compilare se l'albero build non è ben mantenuto. se your'e compilazione sui sistemi embedded, senza spazio di swap. Il compilatore può esaurire la memoria durante il tentativo di compilare un file oggetto massiccio.

E 'successo al lavoro per noi di recente.