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]]

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...

 

[DoB]

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]]

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]

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]]

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.

 

[DoB]

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]]

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?

 

[DoB]

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]

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]

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