È necessario effettuare il wrap delle chiamate su Debugger.Log() nella direttiva #if (DEBUG) per il preprocessore ai fini dell'ottimizzazione del codice, oppure il compilatore C# produrrà ancora codice ottimizzato durante la creazione della configurazione RELEASE?Devo eseguire il wrap delle chiamate su Debugger.Log() in #if (DEBUG)?
Non c'è alcun tipo di ottimizzazione on questo chiamata STAMPA modalità.
La chiamata è presente in IL. L'unica differenza è che non ha alcun effetto se non è presente un DEBUGGER DEBUGGER.
Da documentazione Debugger.Log:
Se non c'è debugger, questo metodo non ha alcun effetto.
Vorrei suggerire di misurare le prestazioni della tua app e dopo scegliere i passaggi da seguire.
Se non ci sono differenze significative (dal punto di vista della vostra app), lascerei quel registro così com'è.
In questo modo, nel momento del bisogno, è possibile collegare al vostro app con debugger e ottenere messaggi potrebbe essere necessario dal registro, come Debugger.Log avrebbe funzionato in quel punto.
un test rapido del seguente codice (.NET 4, di uscita, qualsiasi CPU)
class Program
{
static void Main(string[] args)
{
#if (DEBUG)
Debugger.Log(0, "category", "msg");
#endif
}
}
produce questo IL
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 8
L_0000: ret
}
Come potete vedere c'è nessuna chiamata al Debugger.Log.
Questa è la dichiarazione per Debugger.Log(), come richiamato dalla sorgente di riferimento:
// Posts a message for the attached debugger. If there is no
// debugger attached, has no effect. The debugger may or may not
// report the message depending on its settings.
[MethodImplAttribute(MethodImplOptions.InternalCall)]
public static extern void Log(int level, String category, String message);
Nota che non c'è [condizionale] attributo sul metodo e che porta l'attributo [MethodImplAtttribute]. Ciò significa che il metodo è effettivamente implementato nel CLR, scritto in codice C++.
Quindi il metodo chiama sarà, indipendentemente dalla configurazione. È possibile trovare l'implementazione del metodo dalla distribuzione di origine SSCLI20, clr/src/vm/debugdebugger.cpp. Usa OutputDebugString(), una funzione winapi che mostra le stringhe nel debugger, se ne è collegato uno. O in un'utilità come DbgView.exe di SysInternals. Se nessuno dei due è presente, la chiamata api non fa nulla e ritorna rapidamente. Si paga solo per la funzione chiamata overhead, una manciata di nanosecondi.
Non c'è nulla di decente da ottimizzare sulla chiamata al metodo, essa si comporterà allo stesso modo sia che si costruisca il debug o la configurazione di rilascio. Avere accesso alle informazioni di debug nella versione Release potrebbe essere sicuramente utile, sta a te decidere se questa è una funzionalità che desideri disattivare. È difficile dire se quei nanosecondi abbiano un effetto osservabile sul tuo programma. Misura, non dare per scontato nulla.