[Conditional("DEBUG")] or #if DEBUG

[John Smith]

After reading C# documentation the Conditional attribute seemed the way to
go, but after inspecting the IL it seems those methods are still there and I
imagine the CLR removes them. Using #if DEBUG means the code does not even
reach the IL when compiling in release mode.

Is there any benefit to using the Conditional Attribute? Am I right in
thinking there will small performance overhead using [Conditional("DEBUG")]
over #if DEBUG.

 

[Jay B. Harlow [MVP - Outlook]]

John,
There is no benefit of using [Conditional("DEBUG")] to the called method
itself per se, the benefit is for the calling methods. You can leave all the
calls to a [Conditional("DEBUG")] method and the compiler will quietly
change them into no ops on release builds, or the actual method calls in
debug builds.

What I will do is use both [Conditional("DEBUG")] & #if DEBUG on internal
methods, which will remove the calls & the code for that method from the
assembly, for public methods in class libraries I will use only
[Conditional("DEBUG")] as assemblies compiled against the class library may
or may not have defined DEBUG.

For an example of the use of [Conditional("DEBUG")], see all the methods in
the System.Diagnostics.Debug & System.Diagnostics.Trace classes.

For more details see:
http://msdn.microsoft.com/library/d...vbconConditionalCompilationWithTraceDebug.asp

http://msdn.microsoft.com/msdnmag/issues/01/02/Bugslayer/default.aspx

Hope this helps
Jay

 

[John Smith]

Thank you for the clear and concise answer. Public class libraries seem the
reason d'etre for the Conditional Attribute.

Just to clarify when you say the compiler quietly turns them into nops you
mean the JIT compiler, not the compiler than translates C# into IL.

 

[Christoph Nahr]

I'd say there's another good reason to use the Conditional attribute:
the code that calls the debug method is much easier to read.

With the traditional approach, you can't just #ifdef out the debug
method because the calls to that method will then fail to compile, so
you have to surround them with #ifdef's as well which introduces a
great deal of clutter in the code.

With the Conditional attribute, you can just leave in all the calls,
and the compiler (don't know which one?) will silently remove them in
Release builds at no loss of runtime speed.

 

[Jay B. Harlow [MVP - Outlook]]

John,

Just to clarify when you say the compiler quietly turns them into nops you
mean the JIT compiler, not the compiler than translates C# into IL.

No I mean the C# compiler, as the C# compiler already has enough info (DEBUG
is or is not #defined) to decide to include the call or not. A quick test in
VB.NET there were no operations emitted, not even the noop op code.

You can use ILDASM.EXE to see the difference to the IL generated.

Hope this helps
Jay

 

[dotnetchap [MCAD]]

the code that calls the debug method is much easier to read.
Agreed. That is why I have been using them.
No loss of runtime speed is what I am not 100% convinced of. The methods
remain in IL so there must be some work -no matter how small- done by the
JIT(??) compiler to skip those methods. This is worrying because I was
calling a Conditional method from BeginRequest in global.asax (an ASP.NET
event which is called for every web page). For now I just converted them to
use the untidy #if statement which decompiling to IL proved has no
performance penalty.

 

[Mattias Sjögren]

Hi Jay,

What I will do is use both [Conditional("DEBUG")] & #if DEBUG on internal
methods, which will remove the calls & the code for that method from the
assembly,

Are you using #if #endif only around the method body then? Cause you
can't exclude the entire method, since removing conditional method
calls is done after the "preprocessing" step in the compilation
process. The following doesn't compile if DEBUG isn't defined.

#if DEBUG
[Conditional("DEBUG")]
static void Foo() {}
#endif

static void Main()
{
Foo();
}



Mattias

 

[Mattias Sjögren]

No loss of runtime speed is what I am not 100% convinced of. The methods
remain in IL so there must be some work -no matter how small- done by the
JIT(??) compiler to skip those methods.

JIT compilation is done on a method by method basis. If a method is
never called, it will never be JIT compiled. Also, there's nothing for
the JIT compiler to skip, since the calls are removed by the C#
compiler and aren't present in the IL.

So the only way conditional methods can affect performance is that you
have dead code bloating the assembly the methods are in, which may
cause it to take a millisecond or two longer to load.



Mattias

 

[Jay B. Harlow [MVP - Outlook]]

Mattias,
Yes the method body, as you still need the method itself, for the rest of
the code to compile... I guess I was not as clear as I wanted to be on that
one ;-)

Didn't you and I discuss this once a long time ago. Whoever it was, is why I
add the #if DEBUG to the method body also. Although most of the time I have
the Conditional on public methods, so I don't have a lot using #if DEBUG.

Thanks for clarifying that!
Jay

Hi Jay,

What I will do is use both [Conditional("DEBUG")] & #if DEBUG on internal
methods, which will remove the calls & the code for that method from the
assembly,

Are you using #if #endif only around the method body then? Cause you
can't exclude the entire method, since removing conditional method
calls is done after the "preprocessing" step in the compilation
process. The following doesn't compile if DEBUG isn't defined.

#if DEBUG
[Conditional("DEBUG")]
static void Foo() {}
#endif

static void Main()
{
Foo();
}



Mattias

 

[Mattias Sjögren]

Didn't you and I discuss this once a long time ago.

Not that I recall, but perhaps your memory is better than mine.



Mattias

 

[Jon Skeet [C# MVP]]

Thank you for the clear and concise answer. Public class libraries seem the
reason d'etre for the Conditional Attribute.

Just to clarify when you say the compiler quietly turns them into nops you
mean the JIT compiler, not the compiler than translates C# into IL.

No. For instance:

using System;
using System.Diagnostics;

class Test
{
static void Main(String[] args)
{
ConditionalTest();
}

[Conditional("CONDITION")]
static void ConditionalTest()
{
}
}



Compiling normally, the IL for Main is:

..method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 1 (0x1)
.maxstack 0
IL_0000: ret
} // end of method Test::Main


Compiling with CONDITION defined, the IL for Main is:

..method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 6 (0x6)
.maxstack 0
IL_0000: call void Test::ConditionalTest()
IL_0005: ret
} // end of method Test::Main