Investigate size increase when EventPipe library is enabled in NativeAOT

[LakshanF]

When EventPipe library is opted in for a NativeAOT application (for example, with EventSourceSupport property set to true), the application will increase in size. The EventPipe library is native but looks like the major increase in size comes from managed code. There is managed code that gets enabled with the EventSourceSupport enabled but needs to be investigated further.

A quick investigation by @MichalStrehovsky on the BasicMinimalApi on the NativeAOT ASP.NET benchmark using SizeBench and Sizoscope shows managed code to contribute over 70% of the size increase.

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When EventPipe library is opted in for a NativeAOT application (for example, with EventSourceSupport property set to true), the application will increase in size. The EventPipe library is native but looks like the major increase in size comes from managed code. There is managed code that gets enabled with the EventSourceSupport enabled but needs to be investigated further.

A quick investigation by @MichalStrehovsky on the BasicMinimalApi on the NativeAOT ASP.NET benchmark using SizeBench and Sizoscope shows managed code to contribute over 70% of the size increase.

Author:	LakshanF
Assignees:	LakshanF
Labels:	area-NativeAOT-coreclr
Milestone:	8.0.0

[elinor-fung]

There is managed code that gets enabled with the EventSourceSupport enabled but needs to be investigated further.

Would part of this be re-evaluating whether NativeAOT actually wants all the functionality in EventSource or if it should stub out some parts instead? For example, supporting things like ETW manifest generation (EventSource.GenerateManifest, EventSourceSettings.EtwManifestEventFormat - apparently the default for subclasses) and validation (EventManifestOptions.Strict) seems to pull in a fair bit.

[MichalStrehovsky]

There is managed code that gets enabled with the EventSourceSupport enabled but needs to be investigated further.

Would part of this be re-evaluating whether NativeAOT actually wants all the functionality in EventSource or if it should stub out some parts instead? For example, supporting things like ETW manifest generation (EventSource.GenerateManifest, EventSourceSettings.EtwManifestEventFormat - apparently the default for subclasses) and validation (EventManifestOptions.Strict) seems to pull in a fair bit.

That sounds interesting to look at - if EventPipe doesn't use it, it might even be a good candidate to #if TARGET_WINDOWS in general.

[LakshanF]

One interesting baseline to use would be a trimmed .NET application that uses EventSource. In .NET both EventPipe and EventSourceSupport are enabled by default and understanding any additional managed code that is only in an NativeAOT application would be a good first step.