Thanks for the review@josalem. I don't have any before/after data. The improvement is likely to be low. Ultimately, what caused me to actually submit the PR is that it bugs me that we spend any time in EventPipe when it's disabled (or in ETW when it's disabled but EventPipe is enabled).

In order to implement this for self-describing events, you would need to keep track of the set of enabled keywords perEventProvider, such that as soon as the event is fired, you can & the declared keywords with the keywords enabled for each logger to figure out which logger(s) is/are enabled. Then, you could wrap some of the code in if statements, though honestly, a good chunk of the code must be executed even if only one of the loggers is enabled. The only places before you get toWriteEventRaw where you can save perf for self-describing is some of the EventPipe specific stuff like creating the event handle. Most everything else has to be done in either case. Then, when you get toWriteEventRaw, you can avoid the pinvoke by havingEventProvider.WriteEventRaw no-op if the event is disabled (it would have to do the keywords check again).

My guess is that the self-describing path isn't nearly as worthwhile to implement as the manifest-based path, simply because the overhead of emitting a self-describing event is much higher, and so this wasted pinvoke is likely to get lost in the noise for self-describing events.