We should have a CI pipeline that tests the C version of EventPipe until we have permanently turned on the feature flag. This will help to make sure we don't have any regressions in the meantime.

This issue will track progress towards switching over to the C implementation of EventPipe. Currently, it is behind a feature flag. Before we transition, we should collect the following information:

• code size comparison
  • See @am11's comment below for some rudimentary numbers
• throughput comparisons
  • We should document throughputs for both the C and C++ implementations before removing the C++ implementation.
• regressions analysis with external tools
  • We have tests in the runtime repo that test the IPC protocols and EventPipe directly, but we don't have tests that cover the end-to-end scenario when it comes to dotnet-trace, etw, or other external tools (We do in dotnet/diagnostics though). We should do some local testing to make sure we aren't breaking any scenarios (I doubt we are).
• Regressions from C++
  • Release builds of C impl AV inside ep_buffer_manager_write_event (AV in Release build of C implementation of EventPipe #46158)
  • Checked builds of C assert if app has is being traced during shutdown, e.g., tracing and app to completion. (Assert on process shutdown while tracing C implementation of EventPipe #46159)
    • Perhaps this assert comes from the Mono requirement to be able to clean up an restart execution of the runtime vs CoreCLR's expectation that shutdown will lead to the OS cleaning things up?
    • Not tracked by this issue: we should add a test that tests this scenario as it is expected to work.

CC - @tommcdon @lateralusX