2010-03-30 21 views
13

Nota, la mia domanda non è: come faccio a dire al mio compilatore di compilare con la profilazione.C++ g ++ llvm-clang compiler profiling

Voglio profilo processo di compilazione. Per ogni file, mi piacerebbe sapere quanto tempo è trascorso su ogni riga del programma.

Sto lavorando a un progetto, alcuni file hanno tempi di compilazione enormi, sto cercando di capire perché.

Esiste comunque la possibilità di farlo con g ++ o llvm-clang?

Grazie!

Output di -v -ftime-report (cosa significa?)?

Di seguito è "parser" o "espandere" l'uso di modelli?

Execution times (seconds) 
    callgraph construction: 0.06 (2%) usr 0.00 (0%) sys 0.09 (2%) wall 3181 kB (1%) ggc 
    callgraph optimization: 0.05 (2%) usr 0.00 (0%) sys 0.05 (1%) wall 5243 kB (2%) ggc 
    cfg cleanup   : 0.02 (1%) usr 0.00 (0%) sys 0.02 (0%) wall  11 kB (0%) ggc 
    df live regs   : 0.01 (0%) usr 0.00 (0%) sys 0.01 (0%) wall  0 kB (0%) ggc 
    df reg dead/unused notes: 0.03 (1%) usr 0.00 (0%) sys 0.03 (1%) wall 1993 kB (1%) ggc 
    register information : 0.04 (1%) usr 0.00 (0%) sys 0.04 (1%) wall  0 kB (0%) ggc 
    alias analysis  : 0.01 (0%) usr 0.00 (0%) sys 0.01 (0%) wall  450 kB (0%) ggc 
    rebuild jump labels : 0.03 (1%) usr 0.00 (0%) sys 0.03 (1%) wall  0 kB (0%) ggc 
    preprocessing   : 0.12 (4%) usr 0.06 (12%) sys 1.46 (27%) wall 2752 kB (1%) ggc 
    parser    : 0.67 (21%) usr 0.15 (29%) sys 0.89 (16%) wall 91749 kB (36%) ggc 
    name lookup   : 0.15 (5%) usr 0.12 (24%) sys 0.24 (4%) wall 14384 kB (6%) ggc 
    inline heuristics  : 0.03 (1%) usr 0.00 (0%) sys 0.03 (1%) wall  0 kB (0%) ggc 
    tree gimplify   : 0.06 (2%) usr 0.01 (2%) sys 0.09 (2%) wall 15992 kB (6%) ggc 
    tree eh    : 0.02 (1%) usr 0.01 (2%) sys 0.03 (1%) wall 4405 kB (2%) ggc 
    tree CFG construction : 0.01 (0%) usr 0.01 (2%) sys 0.03 (1%) wall 6636 kB (3%) ggc 
    tree CFG cleanup  : 0.02 (1%) usr 0.01 (2%) sys 0.02 (0%) wall  15 kB (0%) ggc 
    tree find ref. vars : 0.00 (0%) usr 0.00 (0%) sys 0.00 (0%) wall 1870 kB (1%) ggc 
    tree SSA rewrite  : 0.01 (0%) usr 0.00 (0%) sys 0.01 (0%) wall 2357 kB (1%) ggc 
    tree SSA other  : 0.00 (0%) usr 0.01 (2%) sys 0.00 (0%) wall  37 kB (0%) ggc 
    tree operand scan  : 0.01 (0%) usr 0.04 (8%) sys 0.06 (1%) wall 6340 kB (2%) ggc 
    tree SSA to normal : 0.05 (2%) usr 0.00 (0%) sys 0.05 (1%) wall  95 kB (0%) ggc 
    dominance computation : 0.04 (1%) usr 0.00 (0%) sys 0.04 (1%) wall  0 kB (0%) ggc 
    expand    : 0.60 (18%) usr 0.03 (6%) sys 0.71 (13%) wall 45557 kB (18%) ggc 
    varconst    : 0.02 (1%) usr 0.00 (0%) sys 0.02 (0%) wall 3532 kB (1%) ggc 
    jump     : 0.00 (0%) usr 0.00 (0%) sys 0.00 (0%) wall 1745 kB (1%) ggc 
    mode switching  : 0.01 (0%) usr 0.00 (0%) sys 0.01 (0%) wall  0 kB (0%) ggc 
    integrated RA   : 0.35 (11%) usr 0.00 (0%) sys 0.35 (6%) wall 5259 kB (2%) ggc 
    reload    : 0.29 (9%) usr 0.01 (2%) sys 0.31 (6%) wall 6490 kB (3%) ggc 
    thread pro- & epilogue: 0.10 (3%) usr 0.01 (2%) sys 0.13 (2%) wall 4832 kB (2%) ggc 
    final     : 0.19 (6%) usr 0.01 (2%) sys 0.21 (4%) wall 2985 kB (1%) ggc 
    symout    : 0.25 (8%) usr 0.01 (2%) sys 0.26 (5%) wall 27322 kB (11%) ggc 
    TOTAL     : 3.25    0.51    5.49    256741 kB 
+0

Questo è il migliore che si può ottenere. È impossibile vedere il tempo delle singole linee C++, ma qui puoi vedere se il problema riguarda il preprocessore, il parser o una qualsiasi delle altre fasi del compilatore. Il tuo file è stato compilato in soli 3,25 secondi. – bitc

risposta

7

provare queste opzioni della riga di comando con g ++

-v -ftime-report

Questo dovrebbe dare più informazioni sul processo di compilazione. Il colpevole è di solito i modelli però.

+0

Come ultima risorsa puoi commentare le cose per trovare ciò che sta impiegando più tempo. – bitc

1

Per pre-elaborazione linea un po 'più a lungo suggerimento:

"0,12 (4%) usr 0,06 (12%) sys 1,46 (27%) muro" - questa linea dice, che la pre-elaborazione era di fare piccolo lavoro su CPU stesso (0.12), ma utilizza chiamate di sistema piuttosto pesanti (0,06 o il 50% del tempo di CPU dell'utente) e il tempo maggiore è stato sprecato non in CPU (1,46 in tempo reale >> 0,18 s di tempo CPU). Quindi, questa volta è stata sprecata in attesa di un'operazione I/O OPPURE in attesa della CPU sul sistema occupato. Questo è stato l'unico programma di lavoro sulla macchina?

per I/O si può fare: aggiungi noatime a FS per ridurre il numero di I/O reqs I, comprare più veloce (in termini di minori Tempo di ricerca o una maggiore frequenza IO) HDD, fonti mossa clang SSD o addirittura RAM- guida (dispositivo loop). E non puoi fare una deframmentazione, perché è Linux.

Per il significato del passaggio Eash, utilizzare http://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes

+0

Per il significato delle linee: breve introduzione in gcc http://www.cse.iitb.ac.in/~uday/gcc-mini-workshop/gcc-internals-1.pdf Presentazione su RTL http: //www.cse .iitb.ac.in/GRC/gcc-laboratorio-09/downloads/gccw09-rtl.pdf – osgx