Perché gli iteratori provocano un debugging molto lento in VS2010 anche con _HAS_ITERATOR_DEBUGGING, _SECURE_SCL, _SECURE_SCL_THROWS impostato su 0

Question

Ho cercato di rintracciare perché ci vuole così tanto tempo per eseguire il debug del nostro programma in modalità di debug. Dopo aver usato xperf per vedere che aspetto avevano gli stack, era ovvio che stavamo spendendo un'enorme quantità di tempo nell'iteratore e nei container STL. Ho cercato su google questo per un po 'e ho trovato le opzioni

_HAS_ITERATOR_DEBUGGING=0 
_SECURE_SCL=0 
_SECURE_SCL_THROWS=0 

E ho impostato tutti quelli in codice con un #define

#define _HAS_ITERATOR_DEBUGGING 0 
#define _SECURE_SCL 0 
#define _SECURE_SCL_THROWS 0 

ma questo non sembra funzionare, così poi ho provato con le definizioni del preprocessore all'interno del progetto di Visual Studio, ma che ancora non sembra aiutare.

Ho provato praticamente tutte le permutazioni a cui riesco a pensare, inclusa l'impostazione nelle intestazioni e, dopo tutto, gli include, ma non importa quello che faccio, non vedo un aumento delle prestazioni durante il debug. Per fare un esempio, quando si esegue in modalità di rilascio questa serie di operazioni richiede circa 140 secondi. In modalità di debug ci vogliono poco più di 2.400 secondi. Aumento di circa 17-18 volte del tempo di elaborazione.

Alcune informazioni aggiuntive, il processo che ospita queste dll C++ è un processo C# .net 4 e ho attivato il debug del codice non gestito. Fondamentalmente tutto il processo carica le DLL per noi. Tutto il vero lavoro è fatto nel codice C++.

Ho incluso la riga di comando completa del compilatore di seguito.

/I"..\CommonInclude" /Zi /nologo /W4 /WX /Od /Oy- /D "_CRT_SECURE_NO_WARNINGS" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "ENGINE_EXPORTS" /D "_HAS_ITERATOR_DEBUGGING=0" /D "_SECURE_SCL=0" /D "_SECURE_SCL_THROWS=0" /D "_VC80_UPGRADE=0x0710" /D "_WINDLL" /D "_MBCS" /Gm- /EHa /MDd /GS /fp:precise /Zc:wchar_t- /Zc:forScope /GR /Yu"StdAfx.h" /Fp".\Debug/Foo.pch" /Fa".\Debug/" /Fo".\Debug/" /Fd".\Debug/" /Gd /analyze- /errorReport:queue /EHa -Zm350 /MP3 

Tutte le idee perché questo sarebbe lento come è?

Answer 1

Una cosa che fa una grande differenza è che di default le funzioni non sono inline in modalità debug. Ciò aggiunge molto tempo al codice utilizzando molte piccole funzioni di accesso.

Ho programmi in cui la differenza tra la modalità di debug e di rilascio è un fattore 100+, senza dipendere dagli iteratori.

Answer 2

Un paio di cose da provare:

• Utilizzare un profiler, ad esempio, la libera AMD CodeAnalyst in quanto vi darà stack di chiamate ed è generalmente molto più facile da usare rispetto xperf. Anche se hai a che fare con il codice di debug potresti trovare ancora alcuni hotspot
• Creare una versione di release con le ottimizzazioni disattivate (potresti creare una configurazione separata per questo). Questo spegnerà il debug dell'iteratore (nel caso in cui sia la causa del tuo rallentamento), ma potrebbe fornire molte più utili informazioni di debug rispetto a una build di rilascio non elaborata. Verificare che l'opzione per omettere Puntatori trama viene abilitato

Answer 3

Sulla base della sua descrizione, questo salta fuori subito:

Ho cercato di rintracciare il motivo per cui ci vuole tanto tempo per eseguire il debug il nostro programma quando in modalità di debug. Dopo aver usato xperf per vedere che gli stack sembravano ovvi che stavamo spendendo una quantità enorme di del nostro tempo nell'iteratore e nei contenitori STL.

Se si utilizzano i contenitori nodo-based (ad esempio, map, set, unordered_map, unordered_set, multimap, multiset, list, etc.), ed eseguire dal debugger, è possibile riscontrare i problemi che derivano da quei contenitori allocare una tonnellata di oggetti con piccole dimensioni. Quando si esegue un'applicazione dal debugger di Windows, il sistema operativo commuta il mucchio processo al mucchio di debug. Se si dispone di molti contenitori a base di nodi sotto carico, liberando li prendere un sacco di tempo con il mucchio di debug.

una semplice correzione è quello di disabilitare l'heap di debug aggiungendo quanto segue alla sezione Ambiente delle opzioni di debug: _NO_DEBUG_HEAP=1

che disabilita il mucchio di debug.