The operational implications of Renderer Layout Layout in NLog

Question

NLog has the ability to include caller information through ${callsite:className=Boolean:fileName=Boolean:includeSourcePath=Boolean:methodName=Boolean}: visualizer.

I assume that NLog gets a stack trace to implement this function.

I am wondering if this is the case, or if NLog has optimizations that go beyond creating a new stack trace for every log call, and what are the performance implications in an application with a lot of log entries?

Answer 1

The .NET Framework does not provide more options [1] for receiving a stacktrace than for using the StackTrace class, either directly, or through Exception or Environment.StackTrace as a string, so there is a bit more NLog can do. In addition, the call flow will (potentially) be different for each call to the log. The only exception is the call to the log inside the loop. But even in this case, some equipment will be needed to help NLog even know that the call was made from "the same place" as the previous one. This could only be determined by searching (again) in a callstack.

So, in general, I would suggest that NLog should do just that: grab a callstack on every call to the log (although not for every layout / appender that handles the call) - just like log4net, by the way, warns "about this an option that is a performance issue with a high log call frequency.

In any case, you can look at the source, which also indicates (although I did not go through it in the debugger) that there is one column in each log call.

UPDATE . For completeness of use, starting with .NET 4.5, you can use attributes of subscriber information attributes . They have their own "limitations", although, like not including typename. However, they are not currently used by NLog.

[1] Except, perhaps, using some rewriting of the IL level or launching the application in the debugger.