Perché il mio programma scorre più velocemente quando abilito la profilazione?

Question

Ho un programma che funziona abbastanza lentamente (impiega 20 secondi anche al rilascio) quindi, volendo aggiustarlo, ho provato ad usare il profiler incorporato di Visual Studio. Tuttavia, quando eseguo il programma con il profilo abilitato, termina in meno di un secondo. Ciò rende molto difficile trovare un collo di bottiglia. Vorrei postare il codice ma è lungo. Ci sono ragioni ovvie o meno ovvie per cui ciò potrebbe accadere?

MODIFICA: Ok, quindi ho ridotto il problema a un gruppo di chiamate gratuite(). Quando li commento, il programma viene eseguito nella stessa quantità di tempo che ha con la creazione dei profili abilitata. Ma ora ho una perdita di memoria: -/

Answer 1

Sembra molto simile a Heisenbug.

Accadono davvero e possono essere dolorosi da scoprire.

La tua migliore soluzione nella mia esperienza è di cambiare la tua profilazione - possibilmente diversi modi - fino a quando il bug scompare.

Utilizzare diversi profiler. Prova ad aggiungere il codice temporale invece di usare un profiler.

Answer 2

Il modo generale sarebbe dividere-e-conquistare, cioè eseguire solo parti del programma e vedere quando il problema scompare. Ma sembra che tu l'abbia già fatto. Di solito AFAIK non richiede molto tempo, ma malloc può impiegare molto tempo se la memoria è frammentata. Se non si chiama free(), l'heap non viene mai frammentato in primo luogo. (Il codice di profilazione intrusiva potrebbe impedire la frammentazione della memoria allocando piccoli blocchi di dati e colmando le lacune libere - ma ammetto che è una spiegazione un po 'debole).

Forse è possibile aggiungere chiamate manuali di misurazione dell'ora prima/dopo le chiamate a malloc e new e stampare i tempi per verificarlo? Forse puoi anche analizzare i tuoi schemi di allocazione della memoria per scoprire se hai un problema di frammentazione (probabilmente guardando il codice e facendo qualche debugging simbolico nella tua testa ;-)

Answer 3

accendere il profiler finirà per spostare il tuo codice intorno (un po ') che probabilmente maschera il problema.

La causa più comune di hiesenbugs è le variabili unitializzate, la seconda causa più comune è l'utilizzo della memoria dopo che è stata liberata(). Dal momento che il tuo libero sembra aggiustarlo, potresti pensare di cercare i riferimenti tardivi, ma dovrei comunque cercare le variabili non inizializzate prima se fossi in te.

Answer 4

Utilizzare un profiler di campionamento non intrusivo invece di un profiler strumentale invadente.

Answer 5

Potrebbe essere dovuto a poche ottimizzazioni non eseguite dal compilatore quando lo si esegue in modalità di profilazione. Quindi, ti suggerisco di controllare i parametri che vengono passati e controllare la documentazione del compilatore.

Answer 6

Il motivo è perché quando si esegue l'applicazione in Visual Studio, il debugger è collegato ad esso. Quando lo esegui usando il profiler, il debugger non è collegato.

Se si preme F5 per eseguire il programma, anche con la build di rilascio, il debugger è ancora collegato.

Se si tenta di eseguire l'.exe da solo, o di eseguire il programma attraverso l'IDE con "Debug> Avvia senza debug" (o semplicemente premere Ctrl + F5) l'applicazione dovrebbe funzionare veloce come con il profiler.