Good things are hard to kill. One of
the most useful predefined compiler macros
in C/C++ were __FILE__
and __LINE__ which do expand to
the compilation units file name
and line number where this value
is encountered by
the compiler. After 4.5 versions of .NET we are on par with C/C++ again. It
is of course not a simple compiler expandable macro it
is an attribute but it does serve exactly
the same purpose. Now we do get CallerLineNumberAttribute == __LINE__ CallerFilePathAttribute == __FILE__ CallerMemberNameAttribute == __FUNCTION__ (MSVC Extension)
The most important one
is CallerMemberNameAttribute which
is very useful to implement
the INotifyPropertyChanged interface without
the need to hard code
the name of
the property anymore. Now you can simply decorate your change method with
the new CallerMemberName attribute
and you get
the property name as
string directly inserted by
the C# compiler at compile time. public
string UserName
{
get { return _userName; }
set { _userName=value;
RaisePropertyChanged(); // no more RaisePropertyChanged(“UserName”)!
}
}
protected void RaisePropertyChanged([CallerMemberName]
string member = "")
{
var copy = PropertyChanged;
if(copy != null)
{
copy(new PropertyChangedEventArgs(this, member));
}
}
Nice
and handy. This was obviously
the prime reason to implement this feature
in the C# 5.0 compiler. You can repurpose this feature for tracing to get your hands on
the method name of your caller along other stuff very fast now. All infos are added during compile time which
is much faster than other approaches like walking
the stack.
The example on MSDN shows
the usage of this attribute with an example
public static void TraceMessage(string message, [CallerMemberName]
string memberName = "",
[CallerFilePath]
string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0)
{
Console.WriteLine("Hi {0} {1} {2}({3})", message, memberName, sourceFilePath, sourceLineNumber);
}
When I do think of tracing I do usually want to have a API which allows me to
Trace method enter
and leave
Trace messages with a severity like Info, Warning, Error
When I do print a trace message it
is very useful to print out method
and type name as well. So your API must either be able to pass
the method
and type name as strings or extract it automatically via walking back one Stackframe
and fetch
the infos from there.
The first glaring deficiency
is that there
is no CallerTypeAttribute yet because
the C# compiler team was not satisfied with its performance.
A usable Trace Api might therefore look like
enum TraceTypes
{
None = 0,
EnterLeave = 1 << 0,
Info = 1 << 1,
Warn = 1 << 2,
Error = 1 << 3
}
class Tracer : IDisposable
{
string Type;
string Method;
public Tracer(string type,
string method)
{
Type = type;
Method = method;
if (IsEnabled(TraceTypes.EnterLeave,Type, Method))
{
}
}
private bool IsEnabled(TraceTypes traceTypes,
string Type,
string Method)
{
// Do checking here if tracing
is enabled
return false;
}
public void Info(string fmt, params object[] args)
{
}
public void Warn(string fmt, params object[] args)
{
}
public void Error(string fmt, params object[] args)
{
}
public static void Info(string type,
string method,
string fmt, params object[] args)
{
}
public static void Warn(string type,
string method,
string fmt, params object[] args)
{
}
public static void Error(string type,
string method,
string fmt, params object[] args)
{
}
public void Dispose()
{
// trace method leave
}
}
This minimal trace API
is very fast but hard to maintain since you need to pass
in the type
and method name as hard coded strings which can change from time to time. But now we have at least CallerMemberName to rid of
the explicit method parameter right? Not really. Since any acceptable usable trace Api should have a method signature like Tracexxx(…
string fmt, params [] object args) we not able to add additional optional parameters after
the args array. If we would put it before
the format
string we would need to make it optional as well which would mean
the compiler would need to figure out
what our trace message
and arguments are (not likely) or we would need to specify everything explicitly just like before .
There are ways around this by providing a myriad of overloads which
in the end are routed to
the very same method but that
is ugly. I am not sure if nobody inside MS agrees that
the above API
is reasonable to have or (more likely) that
the whole talk about you can use this feature for diagnostic purposes was not a core feature at all but a simple byproduct of making
the life of INotifyPropertyChanged implementers easier.
A way around this would be to allow for variable argument arrays after
the params keyword another set of optional arguments which are always filled by
the compiler but I do not know if this
is an easy one.
The thing I am missing much more
is the not provided CallerType attribute. But not
in the way you would think of.
In the API above I did add some filtering based on method
and type to stay as fast as possible for types where tracing
is not enabled at all. It should be no more expensive than an additional method call
and a bool variable check if tracing for this type
is enabled at all.
The data
is tightly bound to
the calling type
and method
and should therefore become part of
the static type instance. Since extending
the CLR type system for tracing
is not something I do expect to happen I have come up with an alternative approach which allows me basically to attach run time data to any existing type object
in super fast way.
The key to success
is the usage of generics.
class Tracer<T> : IDisposable
{
string Method;
public Tracer(string method)
{
if (TraceData<T>.Instance.Enabled.HasFlag(TraceTypes.EnterLeave))
{
}
}
public void Dispose()
{
if (TraceData<T>.Instance.Enabled.HasFlag(TraceTypes.EnterLeave))
{
}
}
public static void Info(string fmt, params object[] args)
{
}
/// <summary>
/// Every type gets its own instance with a fresh set of variables to describe
the
/// current filter status.
/// </summary>
/// <typeparam name="T"></typeparam>
internal class TraceData<UsingType>
{
internal static TraceData<UsingType> Instance = new TraceData<UsingType>();
public bool IsInitialized = false; // flag if we need to reinit
the trace data
in case of reconfigured trace settings at runtime
public TraceTypes Enabled = TraceTypes.None; // Enabled trace levels for this type
}
}
We do not need to pass
the type as
string or Type object to
the trace Api. Instead we define a generic Api that accepts
the using type as generic parameter. Then we can create a TraceData static instance which
is due to
the nature of generics a fresh instance for every new type parameter. My tests on my home machine have shown that this approach
is as fast as a simple bool flag check. If you have an application with many types using tracing you do not want to bring
the app down by simply enabling tracing for one special rarely used type.
The trace filter performance for
the types which are not enabled must be therefore
the fasted code path. This approach has
the nice side effect that if you store
the TraceData instances
in one global list you can reconfigure tracing at runtime safely by simply setting
the IsInitialized flag to false. A similar effect can be achieved with a global static Dictionary<Type,TraceData> object but big hash tables have random memory access semantics which
is bad for cache locality
and you always need to pay for
the lookup which involves hash code generation, equality check
and an indexed array access.
The generic version
is wicked fast
and allows you to add more features to your tracing Api with minimal perf overhead. But it
is cumbersome to write
the generic type argument always explicitly
and worse if you do refactor code
and move parts of it to other classes it might be that you cannot configure tracing correctly. I would like therefore to decorate my type with an attribute
[CallerType]
class Tracer<T> : IDisposable
to tell
the compiler to fill
in the generic type argument automatically.
class Program
{
static void Main(string[] args)
{
using (var t = new Tracer()) // equivalent to new Tracer<Program>()
{
That would be really useful
and super fast since you do not need to pass any type object around but you do have full type infos at hand. This change would be breaking if another non generic type exists
in the same namespace where now
the generic counterpart would be preferred. But this
is an acceptable risk
in my opinion since you can today already get conflicts if two generic types of
the same name are defined
in different namespaces. This would be only a variation of this issue.
When you do think about this further you can add more features like to trace
the exception
in your Dispose method if
the method
is left with an exception with that little trick I did write some time ago. You can think of tracing as a super fast
and configurable switch to write data to an output destination or to execute alternative actions. With such an infrastructure you can e.g.
Reconfigure tracing at run time.
Take a memory dump when a specific method
is left with a specific exception.
Throw an exception when a specific trace statement
is hit (useful for testing error conditions).
Execute a passed delegate which e.g. dumps additional state when enabled.
Write data to an
in memory ring buffer
and dump it when specific events do occur (e.g. method
is left with an exception, triggered from outside).
Write data to an output device.
….
This stuff
is really useful to have when your code
is in production on a mission critical server
and you need to find
the root cause of sporadic crashes of your application. It could be a buggy graphics card driver which throws access violations into your application (ok with .NET 4 not anymore except if you enable a compatibility flag) where you would like to have a minidump or you have reached after two weeks of operation a state where you need a full memory dump at a specific point
in time
in the middle of an transaction.
At my older machine I do get with this super fast approach 50 million traces/s when tracing
is disabled. When I do know that tracing
is enabled for this type I can walk
the stack by using StackFrameHelper.GetStackFramesInternal to check further if a specific action or output device
is configured for this method which
is about 2-3 times faster than
the regular StackTrace class. Even with one
String.Format I am down to 3 million traces/s so performance
is not so important anymore since I do want to do something now.
The CallerMemberName feature of
the C# 5 compiler
is nice but I would have preferred to get direct access to
the MethodHandle
and not to
the stringified version of it. But I really would like to see a CallerType attribute implemented to fill
in the generic type argument of
the call site to augment
the static CLR type data with run time data.
