1
Vote

Abandon the use of TraceEventCache in PropertyReaders

description

To provide better support for Trace.WriteLine and Debug.WriteLine abandon the use of the TraceEventCache in the {DateTime}, {Callstack}, {ProcessId}, {ThreadId} and {Timestamp}. This is discussed in this post: http://www.thejoyofcode.com/How_to_use_Ukadc_Diagnostics_with_Trace_and_Debug.aspx

comments

sgryphon wrote Jun 3, 2009 at 3:17 PM

The cache probably has "caching" benefits, so I wouldn't throw it away altogether.

The main issues are consistency and performance. If writing the same event to multiple listeners, using DateTime from the cache means that all traces will have the same value (rather than each doing its own call to DateTimeOffset.UtcNow and getting different values). On the performance side only some values are reset when the cache is reused but values like the ProcessId are persistent (presumably they are got once per process).

It is probably better to just add some fallback intelligence, i.e. if TraceEventCache is provided, then write out {DateTime} from it but if it is not provided then fall back on DateTimeOffset.UtcNow; similarly from ProcessId, ThreadId, etc. Looking in Reflector, this is how other listeners, e.g. XmlWriterTraceListener, solve the problem (and it is pretty much what the cache does anyway).

wrote Feb 14, 2013 at 1:48 AM