Con il mini-profiler

Question

Quando si usa il mini profiler, questo significa che il codice di produzione sarà 'sparpagliato' con l'uso dei blocchi?

using (profiler.Step("Set page title")) 
{ 
    ViewBag.Title = "Home Page"; 
} 

Credo che se si tratta di 1-off test ho potuto rimuoverlo, ma di solito si desidera mantenere questi nella base di codice per la costante profilazione.

Answer 1

Questo è in realtà un cattivo esempio: di solito non si profilerebbe qualcosa di banale.

In definitiva, è elettivo ciò che si desidera profilo. C'è un gancio per cose come ADO.NET, ma se vuoi che profili le cose al di fuori di di questo, sì: devi dargli una mano.

Re "disseminato", beh, questo è soggettivo. L'approccio migliore consiste solitamente nel limitare la strumentazione alle operazioni di altissimo livello e quindi eseguire solo l'ingrandimento con operazioni più granulari quante sono necessarie (a causa di un problema identificato); per esempio, si potrebbe avere:

... 
using(profiler.Step("Refresh customer")) 
{ 
    // ... 
} 
... 

e solo quando si scopre che l'assunzione di 1800ms ingrandire:

... 
using(profiler.Step("Refresh customer")) 
{ 
    using(profiler.Step("Query LDAP")) 
    { ... } 
    using(profiler.Step("Query primary customer DB")) 
    { ... } 
    using(profiler.Step("Query aux db")) 
    { ... } 
    using(profiler.Step("Print, scan, and OCR")) 
    { ... } 
} 
... 

C'è anche un metodo .Inline(...) per i singoli comandi.

O se non si pensa che questo sia "littering":

• sottolinea performance is a feature (e anzi, spesso un requisito) - è ok per avere il codice per supportare le caratteristiche! Infatti, è una forma di prova che si dispone considerato (e misurato) la realizzazione di un nuovo pezzo/alterata codice
• è interamente contestuale come granulare ne rendono
• fornisce quindi un livello significativo di dettaglio all'utente - senza folle quantità di trivia nel registro e senza la natura invasiva delle prestazioni della maggior parte del logging