2011-11-28 9 views
34

En Visual Studio 2010, si va a las propiedades de un proyecto y va a la pestaña Compilar, hay una casilla de verificación para "Definir la constante TRACE". Lo cual es el equivalente a hacer un #define TRACE.Defina la constante TRACE en .NET/Visual Studio

Todos los métodos de System.Diagnostics.Trace tienen un [Conditional("TRACE")] alrededor de ellos.

Mi pregunta es ¿por qué podría apagar esto? Quiero decir, si no tiene definido ningún oyente de rastreo, entonces no es como si fuera a llenar un registro o algo así. Me parece extraño. Si está realizando un esfuerzo para realizar llamadas a Trace, ¿por qué no quiere controlarlo a través de App/Web.config, sino que lo controla a través de un compilador, lo que excluye la posibilidad de volver a activarlo sin una recompilación

¿Echo de menos algo? Sin duda, no puede ser tan malo para el rendimiento, ¿verdad?

+5

El seguimiento de llamadas() no es gratuito, incluso si no hay oyentes. Hacerlo muy caro no es difícil. –

+0

No creo que sea lo suficientemente granular. Es posible que desee rastrear solo ciertos tipos de eventos en la implementación (advertencia, error) para registrarlos, mientras que en la depuración es posible que desee todo (información, detallado, etc.). Realmente debería haber TRACE_ERROR, TRACE_VERBOSE, etc. – luksan

+0

Consulte http://stackoverflow.com/questions/6911863/setting-up-ac-sharp-application-for-max-performance-build para obtener más información acerca de TRACE y optimizar su construcción . – MBentley

Respuesta

27

Probablemente, esta casilla es equivalente a la opción del compilador /define:TRACE. Es posible que desee desactivar esta opción para una compilación de versión ya sea porque no desea que los usuarios finales vean la salida de rastreo por algún motivo (por ejemplo, seguridad) o para mejorar el rendimiento. Por supuesto, el aumento del rendimiento dependerá de la cantidad de trabajo que se realice cuando esté activado, pero el Conditional attribute hará que el compilador elimine por completo la llamada de función (incluido cualquier formato de cadena, etc.) del IL generado, por lo que podría hacen una diferencia significativa.

+1

¿Sería correcto decir que la llamada a la función se eliminó por completo, en lugar de reemplazar la llamada por una no operativa? Para mí, esto último me da la impresión de que va a poner un NOP en la IL, pero la página de MSDN vinculada no lo sugiere. – Ashe

+2

Gracias, tienes razón (confirmado por la respuesta de Jon Skeet al final de [este hilo] (http://bytes.com/topic/c-sharp/answers/237540-conditional-debug-if-debug)). He corregido mi respuesta. –