D profilo del compilatore

Question

Come capire quale parte del mio codice d richiede molto tempo per essere compilata?

Ho provato a utilizzare valgrind, ma i nomi dei metodi non erano molto intuitivi. 87% del tempo è stato speso in <cycle 7>, il 40% del tempo in _D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv

Sto cercando qualcosa di simile: il 40% del tempo è stato speso per xy.d, da quel 80% del tempo ha preso la compilazione di vari istanze del modello xyz e un motivo è perché ha usato il memcpy il 99% delle volte.

Sono interessato a profilare sia DMD che LDC.

Answer 1

Poiché il front-end del compilatore D è scritto in D, la profilatura con strumenti convenzionali sarà piuttosto difficile rispetto a qualcosa come C++. Ho avuto un certo successo usando strumenti come gdb e valgrind su Linux e strumenti come VisualD su Windows, gli utenti Mac sono una specie di SOL.

Hai altre cinque opzioni:

1. smettere di cercare di trovare la funzione specifica nel compilatore e girare per la conoscenza comune circa il problema (vedi sotto)
2. utilizzare uno strumento come https://github.com/CyberShadow/DBuildStat. Non ti dà la risposta esatta che stai chiedendo, ma se stai cercando di ottenere un grande progetto per compilare più velocemente è meglio di niente.
3. Utilizzare il flag -v per provare e vedere quali parti del programma impiegano un po 'di tempo. Certo, questo è un approccio molto brutale e può richiedere un po 'di tempo.
4. Modificare il makefile del front-end DMD per utilizzare lo switch -profile. Ogni volta che esegui DMD otterrai un file di profilo con molte informazioni. Certo, non penso che sia mai stato provato. La tua milizia può variare.
5. Prova a chiedere informazioni al team LDC nella pagina dei problemi di Github. Gli IIRC hanno creato una versione con patch per la profilazione che hanno usato per il codice base di Weka.io.

Quando dico rivolgersi a una conoscenza comune, intendo dire che la compilazione lenta è probabilmente dovuta a alcuni problemi comuni. Ad esempio, quando una query SQL impiega troppo tempo, la mia prima reazione è di non provare a profilare il codice del server MySQL. Qui ci sono un paio di problemi più comuni

1. CTFE, mentre accelera il tempo di esecuzione, è lento. Soprattutto se stai facendo modelli ricorsivi come allSatisfy o se usi funzioni come ctRegex. Se stai facendo un pesante CTFE e vuoi delle compilazioni più veloci al prezzo di un possibile codice più lento, prendi in considerazione la possibilità di cambiarle per eseguire le chiamate temporali.
2. DMD non ignora (ancora) i simboli che non sono utilizzati nel programma, nel senso che se si importa un modulo, code-gen avverrà per tutte le funzioni nel modulo. Questo è vero anche per le importazioni selettive. Se non li usi, il linker eliminerà le funzioni dall'eseguibile risultante, ma il compilatore ha comunque impiegato del tempo per compilarle. Evita le importazioni come import std.algorithm; o import std.range;. Utilizzare invece importazioni specifiche del pacchetto come import std.algorithm.iteration : map;.