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.
