I spent some time looking into why an optimized Hello World is 3.8 MB big on Windows. There are two ways to look at this problem: what we do in the compiler to make it this big, and what we do in the class libraries that forces it to be so big. This issue tracks the latter.

With a set of hacks here Hello World can go down to about 2.4 MB. I was focusing mostly on getting the reflection stack out of the binary.

The problems:

• Some pieces of the class library have ETW tracing enabled. This heavily relies on reflection to work and brings pretty much everything into the binary.
• ResourceManager. This is mostly used to bring localized exception messages. Too bad we don't have any in the framework. ResourceManager parses custom attributes, so custom attribute support, reflection method invocation, reflection field access etc. is all brought in.
• Unhandled exception stack trace experience eagerly populates MethodBase when initializing StackFrame, bringing a lot of MethodInfo support in. This is totally my fault. I asked for this to be implemented similar to CoreCLR, but we have good reasons to make StackFrame a bit different.
• Enum.ToString. We'll probably want a more low level version of this. There's no way around not generating this. Someone will box an enum and someone will call a ToString. We'll need to generate this method. It better be lightweight.
• ValueType.Equals/GetHashCode. This reflects on fields. We've heard complaints that when we fall back to this implementation, it's super slow. Maybe we want something more low level here (e.g. small NativeFormat data structures describing field offsets and their types, if valuetype). If we build new data structures, we'll also need to teach the type loader to build them. Fixed in Remove reflection in ValueType.Equals/GetHashCode #5436.
• IsByRefLike. This is implemented as a custom attribute search. Maybe we shouldn't be calling it from the codepath where it's being called right now. Fixed in Move check for IsByRefLike to MakeArrayType #5439.

There are also some other opportunities I didn't measure yet:

• There's still a bunch of type loader left in the image. We're not loading new types. It shouldn't be needed.
• Globalization support. We should look into exposing dummy globalization as a build option.
• Manifest resources. We're still emitting 160 kB of resource strings even though the resource manager is gone.
• There's a bunch more reflection stack in there, mostly to support Object.ToString().