¿Cuál es el impacto en el rendimiento de rastreo en C # y ASP.NET?

Question

He encontrado esto en algún código de inicio de sesión de producción que estaba viendo recientemente ...

HttpContext.Current.Trace.Write(query + ": " + username + ", " + password));

... donde consulta es una consulta SQL corto para agarrar los usuarios que coinciden. ¿Tiene esto algún tipo de impacto en el rendimiento? Asumo que es muy pequeña.

Además, ¿cuál es el propósito de este tipo exacto de traza, utilizando el contexto de HTTP? ¿De dónde viene esta información consigue remontar a? Gracias de antemano!

Answer 1

Sí, va a tener un impacto en el rendimiento cuando la constante de compilación condicional TRACE se define durante la compilación. Hacer cualquier cosa tiene algún tipo de impacto:)

En cuanto a si es o no tiene un impacto significativo en una aplicación. Es muy poco probable que sería tan traza está diseñado para ser ejecutado y se ejecuta en muchas aplicaciones de producción. Sólo un abuso de la función debe conducir a una diferencia de rendimiento notable.

Pero, como siempre, no confía en mí, confía en el generador de perfiles.

Answer 2

Yo no tengo los puntos de reputación para comentarios, pero quería hacer una declaración breve sobre la respuesta de Jonathan. Los números que he visto parecen demostrar que no tiene sentido utilizar StringBuilder por sólo un puñado de concatenaciones de cadenas. La sobrecarga de crear el objeto StringBuilder mayor que el beneficio velocidad de concatenación.

Answer 3

La pérdida más el rendimiento en este pedazo de código no está en la traza, pero en la concatenación de cadenas a través del uso del operador +. Esto hace algunas operaciones de memoria ineficientes que puede vencer a una operación IO en términos de rendimiento. Yo cambiaría a usar algo como string.Concat o la clase StringBuilder (o string.Format para el caso).

Answer 4

Los mensajes de rastreo pueden ir a un montón de lugares diferentes. Se pueden añadir (o eliminar) TraceListeners para la consola, la ventana de depuración VisualStudio, archivos, o el registro de eventos para nombrar unos pocos. Puede incluso crear su propia cuenta.

Además, puede configurar el trazo para no hacer nada cuando se compila para Release.

Por lo tanto, el impacto en el rendimiento de la utilización de traza puede variar mucho, todo el camino desde cero a atascarse por completo su aplicación, dependiendo de lo que los oyentes están activos. La mayoría de los oyentes, sin embargo, tienen sobre el impacto que se espera. Se tarda aproximadamente tanto trabajo escribir en un archivo o base de datos, o en la consola, y localizar no añade mucho relativa por encima de esas actividades de I / O-ligados.

Answer 5

Y si traza está grabando un archivo de texto que va a costar más que escribir a la consola en mi humilde opinión

Answer 6

"Rastreo implica una sobrecarga adicional a las solicitudes y no debe ser habilitado para que las aplicaciones implementadas. Trace.Write () declaraciones, sin embargo, se pueden dejar en porque se ignoran cuando el rastreo no está habilitado."

http://msdn.microsoft.com/en-us/library/ ms972204.aspx

Answer 7

Creo que trace Fuente mira TraceLevel de su interruptor antes de reenviar mensajes a los oyentes. Así que si tenemos el valor por defecto de TraceLevel el interruptor en "error", entonces el rastreo de arriba se reduciría en gran medida, ya que sólo rastros "error" sería enviado a los oyentes.

sólo una suposición ... No he medido nada todavía. Se actualizará si lo hago.

Actualización 2017 : parece ser una obsoleta, sino una forma muy útil de trazar / información de registro en una página .aspx navegador / accesible de forma remota en una aplicación asp.net.

https://msdn.microsoft. com / en-IN / library / z48bew18 (v = vs.71) .aspx