¿Es necesario ajustar las llamadas a Debugger.Log() en la directiva de preprocesador #if (DEBUG) con el fin de optimizar el código, o el compilador de C# aún producirá el código optimizado al construir la configuración RELEASE?¿Debo incluir las llamadas a Debugger.Log() en #if (DEBUG)?
no hay ninguna tipo de optimización en este llamada en LIBERACIÓN modo.
La llamada está presente en IL. La única diferencia es que no tiene ningún efecto si no hay un DEBUGGER presente.
De la documentación Debugger.Log:
Si no hay un depurador asociado, este método no tiene ningún efecto.
Le sugiero que mida el rendimiento de su aplicación y luego elija los pasos a seguir.
Si no hay una diferencia significativa (desde el punto de vista de su aplicación), dejaría ese registro como está.
De esta manera, en el momento de necesidad, se puede adjuntar a su aplicación con depurador y obtener los mensajes que pueda necesitar desde el registro, como Debugger.Log funcionaría en que punto.
Una prueba rápida de la siguiente código (.NET 4, Release, Cualquier CPU)
class Program
{
static void Main(string[] args)
{
#if (DEBUG)
Debugger.Log(0, "category", "msg");
#endif
}
}
produce esta IL
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 8
L_0000: ret
}
Como se puede ver no hay una llamada a la Debugger.Log.
Esta es la declaración de Debugger.Log(), como se recupera de la Fuente de referencia:
// 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);
Tenga en cuenta que no hay [condicional] atributo en el método y que lleva el atributo [MethodImplAtttribute]. Lo que significa que el método se implementa realmente en el CLR, escrito en código C++.
Por lo tanto, la llamada al método se realizará independientemente de la configuración. Puede encontrar la implementación del método a partir de la distribución fuente SSCLI20, clr/src/vm/debugdebugger.cpp. Utiliza OutputDebugString(), una función de winapi que muestra cadenas en el depurador, si hay una adjunta. O en una utilidad como DbgView.exe de SysInternals. Si ninguno de los dos está presente, la llamada de API simplemente no hace nada y vuelve rápidamente. Usted solo paga por la sobrecarga de llamada de función, un puñado de nanosegundos.
No hay nada decente para optimizar acerca de la llamada al método, se realizará de la misma manera ya sea que construya la configuración de depuración o liberación. Tener acceso a la información de depuración en la compilación de Release podría ser útil, depende de usted decidir si esa es una función que desea desactivar. Si esos nanosegundos tienen un efecto observable en su programa es difícil de decir. Mida, no asuma nada.