Abbiamo una grande applicazione C++, che a volte è necessario eseguire come build di debug per indagare sui bug. La build di debug è molto più lenta della build di rilascio, al punto di essere quasi inutilizzabile.Come eseguire le build di debug di MSVC più veloci
Quali trucchi sono disponibili per eseguire le build Debug MSVC eseguite più velocemente senza sacrificare troppo la debugabilità?
Utilizzare #pragma optimize("", off) nella parte superiore dei file selezionati che si desidera eseguire il debug nella versione. Ciò offre una migliore visualizzazione dello stack/variabile.
funziona bene se è solo un paio di file necessari per inseguire il bug in.
Questo è esattamente il trucco che abbiamo scoperto in seguito e che stiamo usando da un po '. (Ho dimenticato di tornare e aggiornare SO). La sintassi corretta è '#pragma optimize (" ", off)', che può essere successivamente seguito da un '#pragma optimize (" ", on)' per riportare il compilatore alla normalità, abilitando così questo trucco per essere usato singole funzioni alla volta. – pauldoo
Grazie per aver segnalato l'errore. L'ho aggiornato. – Macke
profilo l'app e vedere cosa ti sta prendendo il tempo. dovresti quindi essere in grado di vedere quali debug devono essere sintonizzati.
Come è fatto? E che cosa ha a che fare con la creazione di debug build più veloce? – Owl
ci sono diverse differenze tra build di debug e build di rilascio che influenzano sia la debugabilità che la velocità. I più importanti sono la definizione di _DEBUG/NDEBUG, le ottimizzazioni del compilatore e la creazione di informazioni di debug.
Si potrebbe voler creare una terza soluzione di configurazione e giocare con queste impostazioni. Ad esempio, l'aggiunta di informazioni di debug a una build di rilascio non diminuisce le prestazioni, ma si ottiene già una traccia di stack sensibile in modo da sapere in quale funzione si trova. Solo le informazioni sulla linea non sono affidabili a causa delle ottimizzazioni del compilatore.
Se si desidera ottenere informazioni sulla linea affidabili, attivare e disattivare le ottimizzazioni. Questo rallenterà un po 'l'esecuzione, ma sarà comunque più veloce del normale debug purché la definizione di _DEBUG non sia ancora impostata. Quindi puoi fare il debug abbastanza bene, solo tutto ciò che ha "#ifdef _DEBUG" o simili attorno ad esso non sarà lì (ad es. Chiamate per affermare ecc.).
Spero che questo aiuti,
gen
Perché non basta accendere le informazioni di debug nella configurazione di rilascio?
Le informazioni di debug sono già abilitate nel rilascio. Il problema è che molte variabili non sono leggibili nel debugger a causa dell'ottimizzazione aggressiva. – pauldoo
Quale VS stai usando? Siamo passati da VS.net a VS2008 di recente e ho sperimentato la stessa lentezza mentre eseguivo il debug su un dispositivo di fascia alta su un progetto> 500k LOC. Si scopre che la base Intellisense si è corrotta e si aggiornava costantemente ma rimaneva bloccata da qualche parte. L'eliminazione del file .ncb ha risolto il problema.
Stai utilizzando MFC?
Nella mia esperienza, la cosa principale che può rallentare una versione di debug è le routine di convalida della classe, che di solito sono disabilitate nel rilascio. Se la struttura dei dati è a tutti gli alberi, può finire per convalidare i sottoalberi centinaia di volte.
Indipendentemente da ciò, se è, diciamo, 10 volte più lento della versione di rilascio, significa che sta spendendo 1/10 del suo tempo facendo ciò che è necessario e 9/10 facendo qualcos'altro. Se, mentre lo stai aspettando, premi il pulsante "pause" e guarda lo stack delle chiamate, con probabilità 9/10 che vedrai esattamente quale sia il problema.
It's a quick & dirty, but effective way to find performance problems.
abbiamo spento Iterator debug con i simboli del preprocessore:
_HAS_ITERATOR_DEBUGGING=0
_SCL_SECURE=0
ha aiutato un po ', ma era ancora non così rapidamente come vorremmo. Abbiamo anche finito per fare in modo che il debug producesse più release-like definendo NDEBUG invece di _DEBUG. C'erano un paio di altre opzioni che abbiamo cambiato anche io, ma non le ricordo.
È un peccato che abbiamo dovuto fare tutto questo, ma la nostra applicazione ha una certa quantità di lavoro da fare ogni 50ms o è inutilizzabile.VS2008 out of the box ci avrebbe dato ~ 60ms volte per il debug e ~ 6ms volte per il rilascio. Con le modifiche sopra menzionate potremmo ottenere il debug fino a ~ 20ms o così, che è almeno utilizzabile.
Lasciatelo andare piano (cioè continuamente, non attivato dal timer). Quel debug in 10: 1: il rallentamento del rilascio che stai vedendo è solo il tipo di cosa che è davvero facile da trovare con questa tecnica: http://stackoverflow.com/questions/375913/what-can-i-use-to -profile-c-code-in-linux/378024 # 378024 –
... anche a 20: 6 rallentamento, il che significa che il 70% del tempo è sprecato. Quindi, se prendi 10 campioni, vedrai il motivo in pila su 7 +/- 1,45 campioni, e lo stack ti dirà perché lo sta facendo, e sarà una cattiva ragione, che tu possa trovare un work-around . –
In realtà ho eseguito un profiler su di esso. Il problema si è esteso a molti metodi e sembrava che le intestazioni delle funzioni stessero mangiando tutto il tempo, non il corpo. Ho concluso che questo era dovuto ai controlli extra che lo studio visivo stava facendo in modalità di debug. – MrSlippers
Creare un ReleaseWithSymbols configurazione, che definisce NDEBUG e non ha ottimizzazioni abilitate. Questo ti darà prestazioni migliori mantenendo simboli precisi per il debug.
Perché questo è un wiki comunità? – Aamir
In passato mi è stato detto di fare tutte le domande "wiki della comunità". Non so davvero cosa fa l'opzione. – pauldoo
............ lol – demoncodemonkey