On 27.10.2011 16:23, Peter Duniho wrote:
[...]
>> OK, so i need to write
>> if (Logger.DebugEnabled) Logger.Log(...);
>>
>> But what happens in a release build where Logger.Log does not exist
>> because of the Conditional("DEBUG")? Is the condition still evaluated?
>
> Honestly, the whole question smacks of premature optimization to me.
Yes, you are right.
> Logging involves i/o, which is painfully slow compared to practically
> anything else a CPU might do. So it's hard to see how it could actually
> be the case that "evaluating the function arguments" could be "more
> expensive than the logging itself". It'd have to be some pretty
> expensive evaluating going on.
The I/O is write back cached by the OS. This is not that critical as
long as it is not too much.
But some of the log entries calculate some complex aggregate information
over a deep data structure and pass the result as string to the logger.
This cases can really slow down some tasks by a factor 3.
> I'm also suspicious of the concern that logging methods impose
> significant enough overhead that [Conditional("DEBUG")] might provide a
> useful performance improvement.
The main improvement results from not evaluating the function arguments.
The condition check will probably not involve any noticeable overhead.
> Personally, my general preference is to just use .NET's built-in "trace"
> mechanism. It's not the simplest API, but it comes with app.config
> support and is efficient enough that it's used in all sorts of places in
> the .NET framework itself.
Unfortunately we have our own logging API in our company. This API has
some features needed here. The most important are that several
application instances can safely share the same log file and that the
API is implemented in several different platforms. So I have not the
option to use another tracing tool.
> If using my own logging framework, I would
> not worry about overhead until I had some specific performance
> measurements that I could compare with some specific performance goals
> that showed clearly the logging was producing a significant slowdown,
If I put comments in front of a dozen logging calls inside the
applications data cache then some UI actions are about 30-50% faster.
This is significant if the one that does the testing over and over waits
for 20 seconds instead of doing his work.
> and even then I would focus only on the specific performance issues found.
I focus on the different cache hit events for now. But I do not want to
remove the logging completely, because it already has been very helpful
in several cases.
> As an example, I did run across a significant performance problem in a
> logging system last year. But in that case, the problem was that the
> system included caller information as part of the logged output, which
> required a stack trace. The logging system was generating the stack
> trace whether or not the specific level of logging was enabled.
Currently we have no stack trace information unless we log an exception.
In the latter case the stack trace has been examined anyway, isn't it?
> Anyway, all that said: I would guess that the JIT compiler will be smart
> enough to remove logical test (e.g. "if" statements) if those test
> branch around blocks of code that are empty, if it can. Note that if the
> logical test involves calling a method that is not a simple property
> getter, the compiler may not be able to remove the call, because it has
> no way to know that the method call does not involve an important
> side-effect.
Currently I tested something like
/// <summary>Enable Debug-Logging</summary>
#if DEBUG
private static readonly bool EnableLog =
Logger.GetLoggingFlag("MyClass");
#else
private const bool EnableLog = false;
#endif
and
if (EnableLog) Logger.DebugEvent(...);
The performance is fine, but I get dozens of warnings about unreachable
code in release build - although DebugEvent has a ConditionalAttribute.
This is a bit annoying.
> If the test simply compares a field against some constant (and this may
> include a simple property that does the comparison, since those may be
> inlined and the JIT optimizer might do the branch removal after the
> inlining has been performed), then it's possible the IT compiler can
> remove the entire thing.
How can the JIT know that a field does not chance?
Marcel
|
