By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,007 Members | 979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,007 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.
Nov 15 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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/de...TraceDebug.asp

http://msdn.microsoft.com/msdnmag/is...r/default.aspx

Hope this helps
Jay

"John Smith" <so*****@microsoft.com> wrote in message
news:5y*********************@twister.southeast.rr. com...
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.

Nov 15 '05 #2

P: n/a
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.
Nov 15 '05 #3

P: n/a
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.
--
http://www.kynosarges.de
Nov 15 '05 #4

P: n/a
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

"John Smith" <so*****@microsoft.com> wrote in message
news:E3*********************@twister.southeast.rr. com... 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.

Nov 15 '05 #5

P: n/a
>>the code that calls the debug method is much easier to read.
Agreed. That is why I have been using them.
the compiler (don't know which one?) will silently remove them in
Release builds at no loss of runtime speed.

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.
Nov 15 '05 #6

P: n/a
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 [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 15 '05 #7

P: n/a
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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 15 '05 #8

P: n/a
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

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
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 [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Nov 15 '05 #9

P: n/a
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

--
Mattias Sjögren [MVP]
Nov 15 '05 #10

P: n/a
John Smith <so*****@microsoft.com> wrote:
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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.