How heavy is /d:TRACE?

[DoB]

As in the subject...

What is an overhead cost conneted with using the /d:TRACE switch?
The Trace class is a convenient and configurable logger, but it requires the
executable to be built with the /d:TRACE switch.
Is using of the switch heavy in terms of size and performance of the
executable? Is it better to write my own logger class if I want it to be
used in the release build?

DoB

[Jon Skeet [C# MVP]]

Re: How heavy is /d:TRACE?

DoB <DoB@dob.comwro te:

As in the subject...
>
What is an overhead cost conneted with using the /d:TRACE switch?
The Trace class is a convenient and configurable logger, but it requires the
executable to be built with the /d:TRACE switch.
Is using of the switch heavy in terms of size and performance of the
executable? Is it better to write my own logger class if I want it to be
used in the release build?

Its "heaviness" entirely depends on how many calls to Trace you make
within your code.

Personally I prefer the flexibility of log4net (and that's certainly
better than writing your own logging framework) but the choice is
yours...

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[DoB]

Re: How heavy is /d:TRACE?

Its "heaviness" entirely depends on how many calls to Trace you make

within your code.

Do you mean effective calls, or just the all the trace statements inside the
code?

By an effective call I mean the tracing routine being called by the
execution path and actually doing something, e.g. writing to a file.
The call is ineffective when the execution path does not reach it or the
call is made, but no trace listener is defined.

Personally I prefer the flexibility of log4net (and that's certainly
better than writing your own logging framework) but the choice is
yours...

I will take a look at this, thanks.

DoB

[Jon Skeet [C# MVP]]

Re: How heavy is /d:TRACE?

On Dec 18, 1:35 pm, "DoB" <D...@dob.comwr ote:

Its "heaviness" entirely depends on how many calls to Trace you make
within your code.

>
Do you mean effective calls, or just the all the trace statements inside the
code?
>
By an effective call I mean the tracing routine being called by the
execution path and actually doing something, e.g. writing to a file.
The call is ineffective when the execution path does not reach it or the
call is made, but no trace listener is defined.

Well, there'll still be a *small* hit when no trace listener is
defined, but obviously a larger one when there are trace listeners.
The "heaviness" will depend on all of these things.

Jon

[DoB]

Re: How heavy is /d:TRACE?

Well, there'll still be a *small* hit when no trace listener is

defined, but obviously a larger one when there are trace listeners.
The "heaviness" will depend on all of these things.

I do not mind the overhead when the Trace is actually used (i.e. it is
called and the listeners are defined) because this is what I want and
expect.

I was asking for the overhead when Tracing is compiled into the binary and
not used (but possible to use by changing the config file). Is it a good
practice to release application with tracing capabilities built in?

DoB

[Jon Skeet [C# MVP]]

Re: How heavy is /d:TRACE?

DoB <DoB@dob.comwro te:

Well, there'll still be a *small* hit when no trace listener is
defined, but obviously a larger one when there are trace listeners.
The "heaviness" will depend on all of these things.

>
I do not mind the overhead when the Trace is actually used (i.e. it is
called and the listeners are defined) because this is what I want and
expect.
>
I was asking for the overhead when Tracing is compiled into the binary and
not used (but possible to use by changing the config file). Is it a good
practice to release application with tracing capabilities built in?

Well, I think it's good practice to have logging available - but as I
say, I prefer the flexibility of log4net over trace listeners.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[DoB]

Re: How heavy is /d:TRACE?

Well, I think it's good practice to have logging available - but as I

say, I prefer the flexibility of log4net over trace listeners.

Do you know about any comparison of log4net with the enterprise library
logging block?
I also thought of using the enterprise library, but I found it a bit heavy.

DoB

[Jon Skeet [C# MVP]]

Re: How heavy is /d:TRACE?

DoB <DoB@dob.comwro te:

Well, I think it's good practice to have logging available - but as I
say, I prefer the flexibility of log4net over trace listeners.

>
Do you know about any comparison of log4net with the enterprise library
logging block?

Not off-hand, I'm afraid.

I also thought of using the enterprise library, but I found it a bit heavy.

In what sense? Performance? Invasiveness to code?

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[DoB]

Re: How heavy is /d:TRACE?

In what sense? Performance? Invasiveness to code?

Well, do not treat it too serious ;-).
That was just a first impression that this is lots of code, where I wanted
to use something rather simple.

DoB

[DoB]

Re: How heavy is /d:TRACE?

Well, I think it's good practice to have logging available - but as I

say, I prefer the flexibility of log4net over trace listeners.

I am trying with log4net but I am having a problem with logging from class
libraries.

I would like all the libraries to use the same application settings and log
to the same place(s).
Actually, the executing assembly logs OK, but the log output from class
libraries goes... somewhere... probably nowhere ;-).
What could I be doing wrong?

Another but related question: is it a good practice to put the
[assembly: log4net.Config. XmlConfigurator (Watch = true)]
directive inside AssemblyInfo.cs ?

Yours,
DoB

[DoB]

Re: How heavy is /d:TRACE?

I would like all the libraries to use the same application settings and

log to the same place(s).
Actually, the executing assembly logs OK, but the log output from class
libraries goes... somewhere... probably nowhere ;-).
What could I be doing wrong?

OK :-).
The name of the application logger was not inherited by loggers in class
libraries. I correcetd it and now everything is OK.
Anyway I would like to know the answer to the second question :-)

DoB