log4net 性能：我应该在尝试记录之前检查日志级别吗？
如果 log4net 配置中的日志级别设置为信息级别，您是否期望下面的 A) 或 B) 获得更好的性能？ _log.Debug 本身会执行更多代码并花费更长的时间吗？
A)
if(_log.IsDebugEnabled)
_log.Debug("some message");
B)
_log.Debug("some message");
Would you expect better performance from A) or B) below if log level in the log4net config is set to Info level? Will _log.Debug on its own execute more code and take longer?
A)
if(_log.IsDebugEnabled)
_log.Debug("some message");
B)
_log.Debug("some message");
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在这种情况下，我会使用 B。
但是，如果构建日志消息（
log.Debug的参数）可能需要一段时间 - 例如，涉及大量字符串连接 - 那么我会选择答：在“是，记录它”的情况下，它最终会执行两次相同的测试，但在“否，不记录它”的情况下，它不需要构造日志消息。In this case, I'd use B.
However, if constructing the log message (the argument to
log.Debug) may take a while - involving significant string concatenation, for example - then I would go for A. It will end up performing the same test twice in the "yes, log it" case, but it won't need to construct the log message in the "no, don't log it" case.我会选择选项 B 除非日志消息本身需要很长时间来构建。通常情况下的性能增益可以忽略不计，甚至根本不存在。在内部，log4net 执行相同的检查，因此您自己不会更改任何内容。
但正如我所说，在这种情况下，选项 A 可能是一个好主意：
对于所有其他情况，它只是为您记录的每条消息添加三行，这是不值得的。
I would choose option B unless the log message itself takes a long time to construct. The performance gain for the usual case is negligible or doesn't even exist. Internally, log4net does the same check so you won't change anything by doing it yourself.
But as I said, option A may be a good idea in a situation like this:
For all other cases, it just adds three more lines for every message you log which just isn't worth the effort.
之前的分析表明 Log4Net 的
IsXXXEnabled实现并不是最快的，因为它调用了其他几个方法。 NLog 的版本执行易失性读取，因此速度要快得多，但实际上，如果您的瓶颈在于IsXXXEnabled，您已经在做低延迟的事情，并且最终可能会烹饪您自己的专用日志记录。Previous analysis revealed that Log4Net's
IsXXXEnabledimplementation isn't the fastest as it is calling several other methods. NLog's version does a volatile read, so it's much faster, but really, if your bottleneck lies inIsXXXEnabledyou are already doing low-latency stuff and might end-up cooking your own dedicated logging.尽管第一个选项的性能稍高一些，但我不会太担心。
但是，如果您执行以下操作：
那么之前就很有必要检查 _log.IsDebugEnabled。
Even though the first option is slightly more performant I would't worry so much.
However if you do something like this:
then there is a strong case for checking _log.IsDebugEnabled before.
选项 A 更好，因为：
您可能不知道 Debug() 方法后面包含什么。它是一个本地包装器，是有人在传递给 log4net 的 Debug() 调用之前添加的用于处理额外逻辑的本地包装器吗？ log4net 在该方法中做了什么？您可能正在使用 log4net 的源代码来构建程序集，其他团队成员是否更改了它？好的，所以您亲自审核了代码，它非常快，并且您正在使用 Nuget 的程序集，因此您知道您的团队中没有人更改过它。明天新版本的 log4net 发布怎么办？你怎么知道处理 log4net bug 的人没有引入一些日志记录代码来融化你的服务器所有的紧密循环？下一个复制你的代码并对其进行更改的实习生是否和你一样知识渊博，并思考如何进行冗长复杂的日志调用可能比预期的成本更高？另外，请记住，不同的附加程序可能具有不同的日志成本。如果有人将轻量级快速异步附加程序更改为较慢的同步附加程序，会发生什么情况？
底线：防御性编码。这是一个非常简单且廉价的布尔检查，它可以防止大规模和负载下出现一些意外且棘手的性能问题。您是否会看着这张支票说：“我真的很后悔写了这张支票”？不太可能。
Option A is better, because:
You probably don't know what is wrapped behind the Debug() method. Is it a local wrapper that someone added to process extra logic into before passing to log4net's Debug() call? What is log4net doing in that method? You might be using the source for log4net to build your assembly, has another team member changed it? Ok, so you personally audited the code, and it is very fast and you are using the assembly from Nuget, so you know nobody on your team has changed it. What about tomorrow when a new version of log4net drops? How do you know that someone working on a log4net bug hasn't introduced some logging code that melts your server in all your tight loops? Is the next intern who copies your code and makes changes to it as knowledgeable as you are and thinking of how making verbose complex log calls can be more costly than expected? Also, keep in mind that differing appenders might have differing log costs. What happens if someone changes out a lightweight fast async appender for a slower synchronous one?
Bottom line: Code defensively. This is a bool check that is really simple and cheap, and it could prevent some unexpected and tricky performance problems at scale and under load. Are you ever going to look at this check and say, 'I really regret writing that'? Unlikely.