9

Qualcuno può spiegarePerché DbContext.SaveChanges 10x più lento in modalità debug

  1. Perché DbContext.SaveChanges corrono ~ 10 volte più lento in modalità debug di modalità di produzione?
  2. C'è un modo per velocizzare questo?

In modalità di debug, la mia pagina web impiega 116 secondi per caricare rispetto a 15 secondi se avvio il progetto senza debug.

Ho impostato istruzioni di traccia e ho identificato che ~ 100 dei 116 secondi sono spesi nel mio metodo DbContext.SaveChanges in modalità di debug.

Esecuzione del progetto senza eseguire il debug di soli 7 secondi inutilizzati nella stessa sezione.

Fatemi sapere nei commenti se vuoi ulteriori informazioni ..

Project Setup:

  • pagina web ASP.NET
  • VS2012
  • SQLServer2012
  • Entity Framework 5.0

Addizionalmente l Info: (Fammi sapere nei commenti se avete bisogno di più)

  • Il numero cumulativo di query SQL oltre il metodo SaveChanges è di 20.000
  • produzione stringa di connessione: dati Source = PC-DEV; Initial Catalog = aspnet-2013-06-04; Sicurezza integrata = True; MultipleActiveResultSets = True; Nome applicazione = EntityFrameworkMUE
  • Stringa di connessione di debug: origine dati = PC-DEV; catalogo iniziale = aspnet-2013-06-04; sicurezza integrata = True ; MultipleActiveResultSets = True; Nome applicazione = EntityFrameworkMUE
  • Ho anche avuto la stessa prestazione relativa con LocalDB come database di supporto

Aggiornamento:

Come @ruionwriting suggerito, ho fatto il profilo del database e quello che ho trovato è che il ~ 20.000 comandi SQL prendono esattamente nello stesso momento se il progetto viene eseguito in modalità di produzione o di debug. (0 ms per comando).

Tuttavia, la differenza di tempo assoluta in media tra i 20.000 comandi è 5 ms in modalità di debug.

Contrariamente alla modalità di produzione, la differenza di tempo media rispetto al set di comandi è di 0,3 ms.

Questa è la differenza approssimativa di 10 volte in termini di prestazioni e isola il framework di entità come quello che sta impiegando il tempo extra in modalità di debug.

C'è un modo per configurare il debug build in modo che EntityFramework possa essere referenziato senza debugging flags?

E se dovessi in qualche modo ottenere le prestazioni attraverso alcune magie del compilatore, cosa potrei perdere in termini di funzionalità di debug? Al momento non posso entrare nel codice del framework di entità, quindi non credo che mi mancherebbe nulla.

Grazie!

+0

Come si fa la stringa di connessione simile, durante il debug? – RealityDysfunction

+0

@RealityDysfunction ha aggiornato la domanda con la stringa nelle modalità di produzione e di debug. – Jesse

+0

Hai selezionato "Abilita solo il mio codice" in VS? In Menu debug-> Opzioni e impostazioni-> Generale-> Abilita solo il mio codice. Forse hai quello deselezionato e VS sta cercando di eseguire il debug di EF? – Tombala

risposta

18

Whohoo!

Ok, quindi il motivo della modalità di debug era eccezionalmente lento perché Intellitrace di Visual Studio registrava ciascun evento di ADO.NET (tutti i 20.000 di questi) generato da Entity Framework.

Quindi Strumenti-> Opzioni -> IntelliTrace e Deseleziona "Abilita IntelliTrace" risolto il problema.

Oppure si può anche solo filtrare gli eventi ADO.NET andando in Strumenti-> Opzioni -> -> IntelliTrace IntelliTrace Eventi e ADO.NET deselezionare

Grazie per i suggerimenti di tutti.

Una sezione qui parla di Will Intellitrace slow down my app

Come Filter IntelliTrace Events

+1

Questo è applicabile solo a Visual Studio Ultimate. – Vlad

1

Ci sono più performance considerations per EF ed è noto che, compared per molti altri orm, le operazioni possono essere più lente del previsto/desiderato per un orm.

(1a) quando si esegue il debug sarà sempre più lento e (2) la prima corsa dopo la costruzione sarà sempre più lenta.

Tutto ciò può dipendere dalla complessità del modello. Prova a capture the T-SQL statements using SQL Profiler.