Tracing - Perfomance impact.
-
Hello all, I am planning to add Tracing instrumentation to our application. This would result in tons of adding Tracing and logging statements in almost all methods of main areas of application. Even when tracing is disabled, at minimum these statements would atleast evaluate TracingEnabled==False/True logic, which i think will have some performance impact. Any better ideas are appreciated. Thanks.
modified on Friday, November 14, 2008 12:15 PM
-
Hello all, I am planning to add Tracing instrumentation to our application. This would result in tons of adding Tracing and logging statements in almost all methods of main areas of application. Even when tracing is disabled, at minimum these statements would atleast evaluate TracingEnabled==False/True logic, which i think will have some performance impact. Any better ideas are appreciated. Thanks.
modified on Friday, November 14, 2008 12:15 PM
You might want to look at Log4Net and/or an AOP framework like PostSharp. It's hard to say what the actual timing impact will be, but something like this seems more of a performance issue in actually doing the instrumentation IMHO. Scott P
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin -
Hello all, I am planning to add Tracing instrumentation to our application. This would result in tons of adding Tracing and logging statements in almost all methods of main areas of application. Even when tracing is disabled, at minimum these statements would atleast evaluate TracingEnabled==False/True logic, which i think will have some performance impact. Any better ideas are appreciated. Thanks.
modified on Friday, November 14, 2008 12:15 PM
If you can control this behaviour using different builds, you might use ConditionalAttribute Class[^]
The need to optimize rises from a bad design. My articles[^]
-
Hello all, I am planning to add Tracing instrumentation to our application. This would result in tons of adding Tracing and logging statements in almost all methods of main areas of application. Even when tracing is disabled, at minimum these statements would atleast evaluate TracingEnabled==False/True logic, which i think will have some performance impact. Any better ideas are appreciated. Thanks.
modified on Friday, November 14, 2008 12:15 PM
This doesn't help you right now, but you could beg Microsoft to include useful things like proper preprocessor macros the next time they make a programming language. You could fudge it, sorta' like this: void Breakpoint() { #if _BREAK_ENABLED System.Diagnostics.Debugger.Break(); #endif } I'm pretty sure that calls to empty function bodies are effectively eliminated by the time the JIT comes into play, but I could be wrong.
-- Abort, Retry, Hurl computer into the hellfire in which it was forged?
-
Hello all, I am planning to add Tracing instrumentation to our application. This would result in tons of adding Tracing and logging statements in almost all methods of main areas of application. Even when tracing is disabled, at minimum these statements would atleast evaluate TracingEnabled==False/True logic, which i think will have some performance impact. Any better ideas are appreciated. Thanks.
modified on Friday, November 14, 2008 12:15 PM
If you're using .NET 3, I'd consider using Partial methods and the Conditional attribute. A better bet though would be to use Inversion of Control to implement the tracing only when it's needed. Take a look at the Unity framework for more information/details.
Deja View - the feeling that you've seen this post before.
-
If you're using .NET 3, I'd consider using Partial methods and the Conditional attribute. A better bet though would be to use Inversion of Control to implement the tracing only when it's needed. Take a look at the Unity framework for more information/details.
Deja View - the feeling that you've seen this post before.
Thanks all you guys. I will take look at unity framework, which Pete suggested.
-
This doesn't help you right now, but you could beg Microsoft to include useful things like proper preprocessor macros the next time they make a programming language. You could fudge it, sorta' like this: void Breakpoint() { #if _BREAK_ENABLED System.Diagnostics.Debugger.Break(); #endif } I'm pretty sure that calls to empty function bodies are effectively eliminated by the time the JIT comes into play, but I could be wrong.
-- Abort, Retry, Hurl computer into the hellfire in which it was forged?
Scott Bruno wrote:
you could beg Microsoft to include useful things like proper preprocessor macros the next time they make a programming language
It was a deliberate decision to avoid preprocessor macros when the C# language was designed. You can do a lot with them, but they are widely used in ways that make it harder to understand the code, which is the opposite of the philosophy of the C# language.
Despite everything, the person most likely to be fooling you next is yourself.
-
Scott Bruno wrote:
you could beg Microsoft to include useful things like proper preprocessor macros the next time they make a programming language
It was a deliberate decision to avoid preprocessor macros when the C# language was designed. You can do a lot with them, but they are widely used in ways that make it harder to understand the code, which is the opposite of the philosophy of the C# language.
Despite everything, the person most likely to be fooling you next is yourself.
Guffa wrote:
It was a deliberate decision
Oh really? And all this time I thought it was accidental. :rolleyes: I know why they did it. I just disagree with the practice of neutering languages in an attempt to open up platform development to the less capable.
-- Abort, Retry, Hurl computer into the hellfire in which it was forged?