Structured Logging != String Interpolation

Structured logging has been around for a while now in .NET. It's a different way of writing messages to a message store than what has been traditionally done with techniques such as Console.WriteLine(). Unfortunately, I still see a lot of developers who are using structured logging incorrectly. This article is a brief exposure to structured logging, why using string interpolation could be hurting performance and how string interpolation limits usefulness of logs.

The concept of structured logging is that a log entry is more than just a line of text. It is the combination of a message template and the associated data. This is a really important concept to understand. The phrase "message template" is a really important distinction over a simple message as plain text. For example

string firstName = "Larry";
logger.LogInformation("Hello {FirstName}", firstName);        

In the above example, there's a single parameter (FirstName) in the message template "Hello {FirstName". What you see in the message log is an expanded string. What's actually happening under the hood is the message template and the corresponding data are stored as a single unit but together as individual pieces. This makes message logs more machine readable since the data and the message template are both stored. This allows for more efficient filtering, searching and aggregation of log entries. When only plain text is saved, it's more inefficient to search or filter logs - think of grep versus a SQL query. There are some very helpful tools such as Application Insights and Seq that allow you to do some amazing things with structured logs impossible with plain text logs.

Still not impressed? Buried deep in one of the articles on Microsoft Learn on the Logging in .NET and C# page is a green highlight area with a helpful tip:

This is a very diplomatic way of saying, don't use string interpolation for message logs. If you are, you're doing it wrong. Microsoft has even built a code analysis rule telling you don't do this. So it must be important. The reason why you should avoid this is what is important. Not only do you miss out on all the benefits of structured logging, you risk causing performance issues.

.NET has thousands of performance optimizations in the code. One of those performance optimizations is caching the message templates used in structured logging. Therefore, when you use string interpolation instead of structured logging syntax, the cache hit rate plummets causing more "templates" to be cached likely never to be reused, thereby increasing the memory footprint of your application unnecessarily.

What's even more important is understanding the process of handling a log message. Let's say your application log level is currently set to Warning (as it probably should be) and you log an informational message. The informational message will not be written to the log. However, when you are using string interpolation there's a lot that still happens that probably shouldn't. The string is expanded regardless if it is written to the log causing an unnecessary string allocation. Unnecessary in the sense the expanded string is allocated just to throw it all away, unused in the end. What is the performance implication when this is happening on a hot path on a large website? This all starts to become a big deal when memory utilization starts skyrocketing on cloud platforms where you pay for every memory allocation.

This article isn't meant to be a detailed article on structured logging, it's benefits and the consequences of coding things incorrectly. There are a ton of resources available on the web, including a great NDC talk by Nick Chapsis. The purpose of this article is to inform you that while using message templates instead of string interpolation can have real consequences you may not understand. It may feel like a step backwards to the old String.Format() days, but it's actually a major step forward. It may help you write faster, more memory efficient code.

I encourage you to read some of the documentation on the Microsoft Learn website. There's really helpful information available to help you write better code. There's also new logging source generators for improving performance on hot paths to overcome some deficiencies in the standard logging provider. Message logging is more complicated than it used to be so it's time to start increasing your knowledge of how to properly use logging.