Discussion with Kevin Gosse
summary
Discussion covers concrete wins and tradeoffs: Datadog tracer plus continuous profiler work reduces overhead to roughly <=5% CPU while often adding ~+100MB RAM; a .NET profiler prototype in C# exists (goal: remove C++ barrier); coauthoring a second edition of a 1000‑page memory book; guidance uses a three‑step debugging loop—gather data, form a theory, verify—and a prototype WinDbg GPT assistant that generates actionable commands from messy dumps.
AI-written summary · about
chapters (17)
- 0:00Conference welcome
- 3:37Kevin Gosse at Datadog
- 6:14Recent .NET challenges
- 9:05Writing the second edition of the .NET memory book
- 12:18Future of .NET and C#
- 17:15Starting low-level programming
- 23:01WinDbg for .NET debugging
- 25:10Memory dumps with WinDbg
- 33:26Assembly in modern dev
- 35:59High vs low-level debugging
- 40:39APM overhead in Datadog
- 47:04Optimizing Datadog tracer
- 48:51Debugging CPU architectures
- 51:00Native AOT in .NET
- 55:38Tricky debugging scenarios
- 57:33Recent .NET recommendations
- 1:01:14Closing remarks
related talks
01h 00mInvestigating C++ Applications in Production on Linux and Windows
52mApplication-Level Debugging and Profiling: Gaps in the Tool Ecosystem
25mFrom Continuous Profiling to Continuous Optimization
01h 01mDebugging and Profiling .NET Core Apps on Linux
01h 02mThe performance loop—A practical guide to profiling and benchmarking
53mProfiling and Debugging .NET Core Apps on Linux.
59mBuilding your own debugging toolbox with ClrMD
43mSoftware Operations and Human Cognition