Remove some allocation at "hello world" startup

[stephentoub]

Measuring dotnet helloworld.dll that just does Console.WriteLine(“hello world”);, on my machine this reduces startup allocation by ~200 objects / 12Kbytes, and reduces wall-clock time by ~8% (from ~80ms to ~73ms). Wall-clock measurement done with Measure-Command { dotnet helloworld.dll }. Allocation measurements done with VS .NET allocation profiler.

@jkotas, please let me know if you think any of these aren't worthwhile or are problematic in some way and I can roll them back.

Contributes to #44598

cc: @brianrob, @DamianEdwards

---

For future reference, after this there's still quite a bit of allocation, but it's hard to get rid of a lot more without disabling whole swaths of functionality (e.g. disabling EventSource). Here's what remains:

Type	Allocations	Bytes
- System.SByte[]	216	9,456
- System.String	43	34,040
- System.Object[]	14	24,040
- System.Byte[]	4	3,731
- System.Int32[]	4	3,580
- System.Diagnostics.Tracing.EventSource.OverideEventProvider	4	448
- Interop.Advapi32.EtwEnableCallback	4	256
- System.Runtime.CompilerServices.GCHeapHash	4	128
- System.Object	3	72
- System.Text.EncoderReplacementFallback	3	72
- System.Text.DecoderReplacementFallback	3	72
- System.Char[]	2	564
- System.Threading.ThreadAbortException	2	256
- System.IntPtr[]	2	208
- System.Text.UTF8Encoding.UTF8EncodingSealed	2	96
- System.RuntimeType	2	80
- System.String[]	2	56
- System.Collections.Generic.NonRandomizedStringEqualityComparer.OrdinalComparer	2	48
- System.Diagnostics.Tracing.TraceLoggingEventHandleTable	2	48
- System.Diagnostics.Tracing.EtwEventProvider	2	48
- System.Diagnostics.Tracing.EventPipeEventProvider	2	48
- System.WeakReference<System.Diagnostics.Tracing.EventSource>	2	48
- System.Diagnostics.Tracing.RuntimeEventSource	1	368
- System.Collections.Generic.Dictionary<System.String, System.Object>.Entry[]	1	192
- System.Diagnostics.Tracing.NativeRuntimeEventSource	1	184
- System.Exception	1	128
- System.OutOfMemoryException	1	128
- System.StackOverflowException	1	128
- System.ExecutionEngineException	1	128
- System.IO.StreamWriter	1	104
- System.Collections.Generic.Dictionary<System.String, System.Object>	1	80
- System.Threading.Tasks.Task<System.Threading.Tasks.VoidTaskResult>	1	72
- System.RuntimeFieldInfoStub	1	64
- System.EventHandler	1	64
- System.Text.OSEncoding	1	64
- System.Threading.ContextCallback	1	64
- System.AppDomain	1	64
- System.Reflection.RuntimeAssembly	1	48
- System.Text.OSEncoder	1	48
- System.IO.TextWriter.SyncTextWriter	1	48
- System.WeakReference<System.Diagnostics.Tracing.EventSource>[]	1	40
- System.ConsolePal.WindowsConsoleStream	1	40
- System.Threading.Tasks.TaskFactory	1	40
- System.IO.TextWriter.NullTextWriter	1	40
- System.Guid	1	32
- System.Diagnostics.Tracing.ActivityTracker	1	32
- System.Collections.Generic.List<System.WeakReference<System.Diagnostics.Tracing.EventSource>>	1	32
- System.Collections.Generic.GenericEqualityComparer<System.String>	1	24
- System.OrdinalCaseSensitiveComparer	1	24
- System.Collections.Generic.NonRandomizedStringEqualityComparer.OrdinalIgnoreCaseComparer	1	24
- System.OrdinalIgnoreCaseComparer	1	24
- System.IO.Stream.NullStream	1	24
- System.Threading.Tasks.Task.<>c	1	24
- System.EventArgs	1	24

A few notes on the remaining allocations:

• The sbyte[]s are mainly from the JIT reporting inlining decisions, and these are on the managed heap as of Replace multi-loaderallocator hash implementation in MethodDescBackpatchInfo coreclr#22285. Most of the object[]s appear to be as well, coming from reportInliningDecision using GCHeapHash which grows an array.
• The strings are mainly consts as well as initialization key/value pairs passed into AppContext.Setup.
• The byte[]s are from StreamWriter's byte[] buffer, Array.Empty, and EventSource "MetadataForString".
• The char[]s are from StreamWriter's char[] buffer and TextWriter's newline characters array.
• The int[]s are from Dictionary / HashHelpers as well as invariant culture data.
• The IntPtr[]s are from one per EventSource instance, used for its TraceLoggingEventHandleTable.
• The objects are remaining lock objects.
• The EtwEnableCallback / OverideEvent (sic) / EtwEventProvider / EventPipeEventProvider are from EventSource, incurring one for ETW (on Windows) and one for EventPipe multiplied by RuntimeEventSource and NativeRuntimeEventSource.
• Encoding-related objects mostly come from Console's output encoding.
• Exception objects are all singletons pre-allocated by the runtime.
• There's a boxed Guid coming from native runtime code invoked by EventSource.Initialize
• API design of yore led to public readonly static fields for Stream.Null, StreamWriter.Null, and TextWriter.Null, causing Stream/StreamWriter/TextWriter instances to be created when these types are first used.
• Creating a Dictionary causes it to access statics on NonRandomizedStringEqualityComparer, which forces into existence the various singletons on both that class and on StringComparer.
• Task.CompletedTask forces Task's cctor to run which also allocates TaskFactory, a ContextCallback for running Tasks with ExecutionContext, and a closure <>c-related object.
• There are couple more we could easily remove (AppDomain, EventArgs, EventHandler) if we were willing to couple AppContext.OnProcessExit with EventListener.DisposeOnShutdown: right now those are connected by EventSource registering an event handler with AppContext.ProcessExit.

[jkotas]

Nice!

[danmoseley]

API design of yore led to public readonly static fields for Stream.Null, StreamWriter.Null, and TextWriter.Null, causing Stream/StreamWriter/TextWriter instances to be created when these types are first used.

If these aren't commonly needed, could they be lazily created instead?

[stephentoub]

If these aren't commonly needed, could they be lazily created instead?

There's the rub: they're public fields. 😦

[danmoseley]

Oh, right. Ugh, public fields.

[jkotas]

if we were willing to couple AppContext.OnProcessExit with EventListener.DisposeOnShutdown

I would be ok with that. EventSource is tightly coupled with the rest of the runtime in multiple of ways, so one more does not make a huge difference. Make sure to sprinkle it with !IsSupported to make it friendly to trimming.

[brianrob]

LGTM! I like EventSource.WriteEventString change especially, since it's only used for error conditions, but we pay for it all the time.

[stephentoub]

I would be ok with that

Ok, I'll add that.

[GSPP]

API design of yore led to public readonly static fields for Stream.Null, StreamWriter.Null, and TextWriter.Null, causing Stream/StreamWriter/TextWriter instances to be created when these types are first used.

Is it feasible to turn them into properties on a major version of .NET? It seems that callers which recompile should keep working. I don't really see why anyone would access these using reflection.

[marek-safar]

System.String	43	34,040

This looks odd, that would make every string used during init almost 1kb

[stephentoub]

It seems that callers which recompile should keep working

If they recompile against the new surface area, yes. But it's a binary breaking change. So, for example, any netstandard2.0 library that was compiled against the field will break with a MissingFieldException if it runs against a binary that has it instead as a property.

[stephentoub]

This looks odd, that would make every string used during init almost 1kb

It's not that every string is 1K. It's that most of the strings are small, but then there's one 30K-ish string (created by the char* passed to AppContext.Setup) for the TPA list.