Esiste una differenza (di prestazioni) tra il debug e il rilascio?

Question

Sto usando MySql Connector .NET per caricare un account e trasferirlo al client. Questa operazione è piuttosto intensa, considerando gli elementi figlio dell'account da caricare.

In modalità di debug, richiede al massimo 1 secondo per caricare l'account. La media sarebbe di 500ms. In modalità di rilascio, sono necessari da 1 a 4 secondi per caricare l'account. La media sarebbe 1500ms.

Poiché non esiste una direttiva #if DEBUG o simile nel mio codice, mi chiedo da dove viene la differenza.

Esiste un'opzione di creazione progetto che è possibile modificare? O ha a che fare con MySql Connector .NET che avrebbe comportamenti diversi a seconda della modalità di compilazione?

MODIFICA: monitoraggio zecche. prende

uscita 20x il tempo di debug richiederà (confronto media):

Debug (Average: 213000 ticks) 
730000 
320000 
60000 
50000 
190000 
130000 
210000 
180000 
160000 
110000 
390000 
270000 
150000 
190000 
230000 
210000 
150000 
200000 
190000 
140000 

Release (Average: 4404500 ticks) 
12940000 
170000 
180000 
80000 
80000 
130000 
120000 
5060000 
5090000 
130000 
50000 
10430000 
25160000 
150000 
160000 
130000 
17620000 
10160000 
100000 
150000 

confronto.

4.404.500/213.000 = 20

Ora la prima operazione è infatti più lungo, ma in generale, quindi sono tutte le altre volte per il rilascio. Qualche idea?

EDIT 2: ho aggiunto anche un test più ampio che calcola il tempo totale. Per 50 carichi di account, ci vogliono in media 4 secondi nei debug e 40 secondi nel rilascio. Sto iniziando a diventare piuttosto disperata su questo - si tratta di un serio problema di prestazioni per la mia applicazione. Qualcuno ha una supposizione su come risolvere questo problema?

Answer 1

Ho capito, ho permesso il codice non sicuro in una delle mie dipendenze costruire. Mi sto ancora chiedendo perché si stia comportando così, ma dovrò scavare un po 'di più.

Grazie per tutto il vostro aiuto!

Answer 2

È possibile che la differenza di tempo sia dovuta a una modifica quando vengono caricati gli assiemi necessari per l'operazione.

Nella modalità di rilascio, il runtime potrebbe non essere necessario caricare immediatamente un assembly che è solo successivamente richiesto dall'operazione (a causa delle varie ottimizzazioni eseguite per le versioni di rilascio). Di conseguenza, in modalità di debug un assembly può essere caricato prima di iniziare a cronometrare l'operazione e in modalità di rilascio tale assembly può essere caricato dopo aver avviato il cronometraggio dell'operazione. Il tempo per caricare l'assembly potrebbe essere significativo a seconda di quanto è grande l'assembly. Ovviamente l'assembly deve essere caricato in entrambi i casi e deve essere caricato una sola volta, quindi le esecuzioni successive in modalità di rilascio potrebbero essere più veloci.

Provare a eseguire l'operazione più volte all'interno di un ciclo e ignorando la prima esecuzione per trovare la media in meno di avvio sovraccarico.

Aggiornamento: Interessante il fatto che i tempi in modalità di rilascio variano molto rispetto a quelle in modalità debug (il dev std è 100x più alta per la modalità di rilascio). Nella parte inferiore, i tempi della modalità di rilascio sono paragonabili a quelli in modalità di debug. Nella tua domanda hai menzionato che il caricamento di un account è intenso a causa di tutti gli elementi figlio che devono essere caricati. Un'altra differenza potrebbe essere il punto in cui il runtime decide di eseguire la garbage collection. Per provare, puoi provare a eseguire System.GC.Collect() dopo ogni operazione (fuori dal tuo timer) e vedere se questo cambia le cose.

Aggiornamento: Se si sospetta che ci può essere un cambiamento nel comportamento rispetto alla chiusura, si potrebbe considerare l'utilizzo del monitor Windows Performance di monitorare i vari contatori .NET LocksAndThreads CLR per il processo dell'applicazione (es), mentre si eseguire i test in entrambe le modalità di debug e di rilascio. Forse non stai rilasciando correttamente un lucchetto da qualche parte e l'esecuzione è ritardata fino a quando non scadono alcuni timeout? Se è così, mi aspetto di vedere un aumento del tasso di contesa riportato dai contatori delle prestazioni. Non sono sicuro del motivo per cui questo sarebbe solo un problema per i build di rilascio (a meno che non si stia effettivamente utilizzando il debugger durante l'esecuzione delle build di debug).

Answer 3

Tutte le schede di creazione e debug nelle impostazioni delle proprietà dell'applicazione possono variare in base alla configurazione di generazione. Alcuni di questi si riferiscono solo alla fase di compilazione e non influenzano le prestazioni del runtime (Consenti codice non sicuro, Errori e avvisi, Tratta avvertimenti come errori e file di documentazione XML). Gli altri potrebbero fare la differenza.

Prendere nota di ogni impostazione diversa tra le configurazioni, quindi modificare ciascuna di esse in modo che le configurazioni corrispondano, verificando tra ciascuna modifica. Quindi dovresti essere in grado di trovare la fonte del problema.

Vorrei testare la costante DEBUG, Definire costante TRACE, Simboli di compilazione condizionale, Target piattaforma, Codice ottimizzazione, (nella schermata Avanzate) Verificare l'overflow/underflow aritmetico, Generare l'assembly di serializzazione, Abilitare il debug del codice non gestito e Abilitare il processo di hosting di Visual Studio.