La presenza di così tanti macro (#define) aumenta il tempo di compilazione a causa di una pre-elaborazione prolungata?

1

In un modo molto semplicistico, capisco:

"Compilation" = "Pre-processing" + "Parsing" + "Linking" + "Executable"

Tutte le macro e altre direttive di pre-elaborazione sono prese in considerazione nella fase di "Pre-elaborazione" stessa.

Supponiamo, se abbiamo diversi macro nel codice sorgente, allora causeranno un tempo significativo nella fase di pre-elaborazione?

Per chiarire, sto parlando dei macro che sono #define d nel file di intestazione, ma non sono #undef ed in quello stesso file per un motivo o per nessun motivo.
Grazie alla sua praticità, sarà utile se qualcuno ha informazioni di profilazione su questo argomento.

    
posta iammilind 15.04.2016 - 08:58
fonte

1 risposta

4

Oggi, la pre-elaborazione sta effettivamente accadendo all'interno del compilatore (ad esempio all'interno dell'eseguibile cc1plus avviato dal comando g++ ). Usa g++ -C -E per ottenere il modulo preelaborato.

La pre-elaborazione e l'analisi sono un'arte ben nota e non richiede molto tempo. Tuttavia, le intestazioni standard di C ++ 11 (ad esempio <vector> o <map> ) spingono un lotto di elementi. Ad esempio, #include <vector> sta spingendo circa diecimila righe di codice su GCC / Linux con GCC 5. Questo è uno dei motivi per cui la compilazione del codice C ++ è lenta (un'altra ragione è che C ++ è incredibilmente sensibile al contesto, l'analisi è lenta: funzioni sovraccaricate, ambiguità di denominazione, ecc ...).

Oggi molte migliaia di macro quasi inutilizzate #define -d non sono un problema. (forse avere milioni di #define potrebbe essere un problema, ti lascio provare) Guarda il codice sorgente di GTK o di Linux kernel per alcuni esempi.

Il motivo per cui non è un vero problema oggi (sugli attuali laptop e desktop, con ad esempio 8GByte di RAM) è che per lo più riempie alcune tabelle di simboli e queste tabelle possono gestire regolarmente centinaia di migliaia di simboli.

Tieni presente che ottimizzare i compilatori richiede molto tempo nell'ottimizzazione. E il codice C ++ ha praticamente bisogno di essere ottimizzato (in particolare, perché ha molte funzioni di membri inline banali, in particolare nell'istanza del template per lo standard contenitori , ecc ...). Anche il codice C deve essere ottimizzato (perché gli attuali processori multicore out-of-order multicore sono molto diversi dai processori del secolo precedente per i quali è stato progettato C).

Se sei curioso di sapere dove il compilatore GCC sta spendendo il tempo della CPU (vedi anche questa domanda) passa -freport-time a g++ (e anche -Wall -O2 per esempio). Se sei ancora più curioso, personalizza il tuo compilatore GCC con MELT (ma ciò richiede di capire qualcosa sugli interni di GCC, che richiede settimane).

Si noti che la compilazione C (non C ++) è "veloce" per la sua pre-elaborazione & fasi di parsing (la maggior parte del tempo di CPU avviene nei passaggi di ottimizzazione; sperimentalmente, con gcc -O2 , il tempo di compilazione è proporzionale al quadrato della "dimensione" della funzione compilata più grande). Se non ti interessa il codice ottimizzato potresti persino provare il compilatore tinycc (che compila circa dieci volte più velocemente di GCC o Clang, ma produce slow codice macchina).

    
risposta data 15.04.2016 - 10:15
fonte

Leggi altre domande sui tag