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.
