I\u2019ve been talking about doing managed heap performance analysis with ETW events for ages because ETW is just such a powerful tool. It has a well defined format so many components, from kernel modes to user mode ones, all emit ETW events which means you can have tools that just know how to parse the event format and correlate them. At Microsoft perf teams have analysis that tells you \u201cthis long request took X ms and X0 ms was due to a kmode component0, X1 ms was due to a umode component1 and etc\u201d by interpreting ETW events. This is immensely useful.<\/p>\n
However, you do need admin privilege to turn on ETW events which is not always desirable. Also I myself am moving part of my development to Linux due to the cross-plat nature of coreclr so I started to look at other eventing mechanisms more closely, from both GC\u2019s and customers\u2019 POV. I had heard of EventSource<\/a>\/EventListener<\/a> before but had never used it myself. These had existed on desktop CLR for years and managed components were using them to fire events. In coreclr 2.2 we made it possible to obtain the CLR runtime events (eg. the GC events) via this mechanism. And I was talking to our diagnostics expert Noah Falk<\/a> who mentioned it\u2019s super simple to get the GC events if that\u2019s all I cared about. Now, for GC\u2019s own perf analysis, I absolutely do care about other events (mostly kernel events). But for customers, it\u2019s usually sufficient to get just the informational level GC events. It turned out it\u2019s literally 10 lines of code to just get the GC events, in process, in managed code \u2013<\/p>\n