Protocol Buffers by Google are a great mechanism for serializing (and deserializing) structured data in a very fast and efficient way. Protobuf-net is Marc Gravell’s port of Protocol Buffers for the .NET ecosystem.

While being very efficient, protobuf-net has a big issue when deserializing .NET’s DateTimes. Behind the scenes DateTimes are converted into Unix-Time which is a count (of ticks in this case) starting from the Unix Epoch (1970/01/01 UTC). When deserializing back to .NET protobuf-net adds that count to a DateTime representing the Epoch-Time resulting in the correct DateTime value. The issue with this process is that it loses the DateTime’s original DateTimeKind.

While profiling our application’s performance we stumbled upon a surprising contention point inside System.Threading.Timer (I say surprising as System.Threading.Timer is the more appropriate timer for multi-threaded environments out of the available timers)

This can be demonstrated by executing the following piece of code:

Back in the olden days of .NET 4.0 we didn’t have Task.Run. All we had to start a task was the complicated Task.Factory.StartNew. Among its parameters there’s a TaskCreationOptions often used to specify TaskCreationOptions.LongRunning. That flag gives TPL a hint that the task you’re about to execute will be longer than usual.

Nowadays with .NET 4.5 and above we mostly use the simpler and safer Task.Run but it isn’t uncommon to wonder how do you pass TaskCreationOptions.LongRunning as a parameter like we used to do with Task.Factory.StartNew.

Trace.CorrelationManager.LogicalOperationStack enables having nested logical operation identifiers where the most common case is logging (NDC). Evidently it doesn’t work with async/await.