Look Mommy, No GC!
summary
Perfmon, ETW GC events and PerfView traces identify a process spending 50–60% of CPU in GC and reveal the stack: string concatenation causes many allocations (huge LOH and many strings from a tokenizer). Static Roslyn heap analyzers and BenchmarkDotNet benchmarks show concrete causes and numbers: non‑IEquatable structs force boxing and allocate heavily, lambdas that close over locals allocate helper objects, LINQ one‑liners run ~10× slower than a loop. Changes like IEquatable, StringBuilder, avoiding captures and reducing LOH cut memory traffic and GC overhead by orders of magnitude.
AI-written summary · about
chapters (8)
- 0:00Start
- 4:28PERFORMANCE COUNTERS
- 6:33PERFMON
- 8:20DIVE DEEPER WITH EVENT TRACING FOR WINDOWS
- 15:54STATIC CODE ANALYSIS
- 18:53DYNAMIC MEMORY PROFILING
- 30:08HOW DOES SEARCHING WORK?
- 52:25SUMMARY
related talks
44mStaying friendly with the GC
43mThe .NET Garbage Collector
06mInterview
42mMeasure Twice, Optimize Once: Real-World .NET Profiling with Visual Studio
01h 03mTurbocharged: Writing High-Performance C# and .NET Code
01h 00mWriting Allocation Free Code in C#
52mGC Tuning & Troubleshooting Crash Course
39mMemory Efficient Java