¿Podría esperar un mejor rendimiento de A) o B) a continuación si el nivel de registro en la configuración de log4net está establecido en el nivel de información? Will _log.Debug en sí mismo ejecutará más código y tomará más tiempo?rendimiento de log4net: ¿debo verificar el nivel de registro antes de intentar iniciar sesión?
A)
if(_log.IsDebugEnabled)
_log.Debug("some message");
B)
_log.Debug("some message");
En este caso, me gustaría usar B.
Sin embargo, si la construcción del mensaje de registro (el argumento de log.Debug) puede tómate un tiempo -que implica una concatenación significativa de cadenas, por ejemplo-, luego iría por A. Terminará realizando la misma prueba dos veces en el caso de "sí, registrarlo", pero no será necesario construir el registro mensaje en el caso "no, no lo registra".
Aunque la primera opción es un poco más eficiente, no me preocuparía tanto.
Sin embargo, si se hace algo como esto:
_log.Debug(String.Format("{0} {1} {2}...", param1, param2, param3));
entonces hay un caso fuerte para la comprobación _log.IsDebugEnabled antes.
Elegiría la opción B a menos que el mensaje de registro tarde mucho tiempo en construirse. La ganancia de rendimiento para el caso habitual es insignificante o incluso no existe. Internamente, log4net hace la misma verificación para que no cambie nada al hacerlo usted mismo.
Pero como ya he dicho, la opción A puede ser una buena idea en una situación como esta:
if (_log.IsDebugEnabled())
{
var message = createComplicatedLogMessageThatTakesALotOfTime();
_log.Debug(message);
}
Para todos los demás casos, que sólo añade tres líneas más por cada mensaje de registro que no es Vale la pena el esfuerzo.
El análisis anterior reveló que la implementación de Log4Net IsXXXEnabled no es la más rápida ya que está llamando a varios otros métodos. La versión de NLog tiene una lectura volátil, por lo que es mucho más rápida, pero realmente, si su cuello de botella se encuentra en IsXXXEnabled, ya está haciendo cosas de baja latencia y podría terminar cocinando su propio registro dedicado.
opción A es mejor, porque:
Es probable que no sabe lo que está envuelto detrás del método de depuración(). ¿Es un contenedor local que alguien agregó para procesar la lógica extra antes de pasar a la llamada a Debug() de log4net? ¿Qué está haciendo log4net en ese método? Puede que esté utilizando la fuente de log4net para construir su ensamblaje, ¿lo ha cambiado otro miembro del equipo? Ok, entonces usted personalmente auditó el código, y es muy rápido y está usando el ensamblaje de Nuget, para que sepa que nadie en su equipo lo ha cambiado. ¿Qué pasa mañana cuando una nueva versión de log4net cae? ¿Cómo sabe que alguien que trabaja en un error de log4net no ha introducido algún código de registro que derrita su servidor en todos sus bucles ajustados? ¿Es el próximo interno que copia su código y hace cambios tan conocedores como usted y piensa en cómo hacer llamadas de registro complejas prolijas puede ser más costoso de lo esperado? Además, tenga en cuenta que los diferentes apéndices pueden tener costos de registro diferentes. ¿Qué sucede si alguien cambia un apilador asíncrono rápido ligero por otro más lento y sincrónico?
Conclusión: código de forma defensiva. Este es un cheque de seguridad que es realmente simple y barato, y podría evitar algunos problemas de rendimiento inesperados y engañosos a gran escala y bajo carga.¿Alguna vez mirará este cheque y dirá: "Realmente lamento escribir eso"? Improbable.
Para la depuración este puede ser el caso, pero para otros métodos como log() y después de mirar cientos de líneas de verificación de declaraciones if, entonces está comenzando a hinchar el código y no tener sentido. – user441521
¿podría ser más específico acerca de su "análisis anterior"? – Zonko
Capturar un descompilador y acceder a IsXXX de Log4Net habilitado: saltas a través de muchas llamadas a métodos virtuales. –