You are doing logging in .NET wrong. Let’s fix it
summary
Shows concrete fixes: stop interpolating or concatenating log text (it allocates strings and boxes values, causing heap pressure and GC pauses), use structured logging with named template parameters so IDs and statuses are searchable, prefer C#10 string interpolation handlers or the LoggerMessage source generator to avoid unnecessary boxing, tune category log levels (default to warning for noisy frameworks), and use Serilog/Application Insights/Datadog appropriately — these changes measurably cut allocations and reduce latency.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 3:14Why this talk exists
- 7:26String interpolation cost in logging
- 13:10Stack vs heap in .NET
- 17:42Heap allocations and performance
- 21:11Excessive logging strings
- 24:42Structured logging
- 28:59Avoid boxing for log levels
- 35:00Logger source generators
- 38:57Custom interpolation dangers
- 41:48Log level tuning
- 45:21Logging only what’s necessary for a good story
- 46:23Optimization myths
- 49:09Summary and Q&A
related talks
54mYou are doing logging in .NET wrong. Let’s fix it.
57mDon’t need to understand the details of .NET. Until you do
20mStructured Logging for the Standard Library
04mInterview
29mLogging the right way
29mApplication Logging
42mMeasure Twice, Optimize Once: Real-World .NET Profiling with Visual Studio
01h 06mGet Better App Performance with this One Weird Trick