Remove unnecessary indirect use of managed wcslen from AppContext setup

[kg]

At least on mono, during AppContext setup we use the string::.ctor(char*) constructor, which calls a managed, vectorized implementation of wcslen - this pulls in a bunch of vector code to optimize a codepath that is cold:

Generating (wrapper managed-to-managed) string:.ctor (char*) (7 byte(s)) dotnet.native.js:1345:16
Generating string:Ctor (char*) (57 byte(s)) dotnet.native.js:1345:16
Generating string:wcslen (char*) (7 byte(s)) dotnet.native.js:1345:16
Generating System.SpanHelpers:IndexOfNullCharacter (char*) (339 byte(s)) dotnet.native.js:1345:16
Generating System.SpanHelpers:UnalignedCountVector128 (char*) (16 byte(s)) dotnet.native.js:1345:16
Generating System.SpanHelpers:GetCharVector128SpanLength (intptr,intptr) (14 byte(s)) dotnet.native.js:1345:16
Generating System.Runtime.Intrinsics.Vector128:AsByte<uint16> (System.Runtime.Intrinsics.Vector128`1<uint16>) (7 byte(s)) dotnet.native.js:1345:16
Generating System.Runtime.Intrinsics.Vector128:As<uint16, byte> (System.Runtime.Intrinsics.Vector128`1<uint16>) (23 byte(s)) dotnet.native.js:1345:16
Generating System.ThrowHelper:ThrowForUnsupportedIntrinsicsVector128BaseType<uint16> () (15 byte(s)) dotnet.native.js:1345:16
Generating System.Runtime.Intrinsics.Vector128`1<uint16>:get_IsSupported () (346 byte(s)) dotnet.native.js:1345:16
Generating System.ThrowHelper:ThrowForUnsupportedIntrinsicsVector128BaseType<byte> () (15 byte(s)) dotnet.native.js:1345:16
Generating System.Runtime.Intrinsics.Vector128`1<byte>:get_IsSupported () (346 byte(s)) dotnet.native.js:1345:16
Generating System.Buffer:Memmove<char> (char&,char&,uintptr) (81 byte(s)) dotnet.native.js:1345:16

We also use the default comparer when creating an instance of Dictionary<string, object>, which pulls in GenericEqualityComparer and NonRandomizedStringEqualityComparer stuff we don't need when we could just use an OrdinalComparer directly:

Generating System.Collections.Generic.EqualityComparer`1<string>:get_Default () (38 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.EqualityComparer`1<string>:CreateComparer () (191 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.GenericEqualityComparer`1<string>:.ctor () (7 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.EqualityComparer`1<string>:.ctor () (7 byte(s)) dotnet.native.js:1345:16
Generating System.Threading.Interlocked:CompareExchange<System.Collections.Generic.EqualityComparer`1<string>> (System.Collections.Generic.EqualityComparer`1<string>&,System.Collections.Generic.EqualityComparer`1<string>,System.Collections.Generic.EqualityComparer`1<string>) (56 byte(s)) dotnet.native.js:1345:16
Generating System.Runtime.CompilerServices.Unsafe:IsNullRef<System.Collections.Generic.EqualityComparer`1<string>> (System.Collections.Generic.EqualityComparer`1<string>&) (16 byte(s)) dotnet.native.js:1345:16
Generating (wrapper managed-to-native) System.Threading.Interlocked:CompareExchange (object&,object&,object&,object&) (16 byte(s)) dotnet.native.js:1345:16
Generating (wrapper runtime-invoke) object:runtime_invoke_direct_void (object,intptr,intptr,intptr) (112 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.NonRandomizedStringEqualityComparer:.cctor () (46 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.NonRandomizedStringEqualityComparer/OrdinalComparer:.ctor (System.Collections.Generic.IEqualityComparer`1<string>) (8 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.NonRandomizedStringEqualityComparer:.ctor (System.Collections.Generic.IEqualityComparer`1<string>) (14 byte(s)) dotnet.native.js:1345:16
Generating System.StringComparer:get_Ordinal () (6 byte(s)) dotnet.native.js:1345:16
Generating (wrapper runtime-invoke) object:runtime_invoke_direct_void (object,intptr,intptr,intptr) (112 byte(s)) dotnet.native.js:1345:16
Generating System.OrdinalCaseSensitiveComparer:.cctor () (11 byte(s)) dotnet.native.js:1345:16
Generating System.OrdinalCaseSensitiveComparer:.ctor () (8 byte(s)) dotnet.native.js:1345:16
Generating System.OrdinalComparer:.ctor (bool) (14 byte(s)) dotnet.native.js:1345:16
Generating System.StringComparer:.ctor () (7 byte(s)) dotnet.native.js:1345:16
Generating System.StringComparer:get_OrdinalIgnoreCase () (6 byte(s)) dotnet.native.js:1345:16
Generating (wrapper runtime-invoke) object:runtime_invoke_direct_void (object,intptr,intptr,intptr) (112 byte(s)) dotnet.native.js:1345:16
Generating System.OrdinalIgnoreCaseComparer:.cctor () (11 byte(s)) dotnet.native.js:1345:16
Generating System.OrdinalIgnoreCaseComparer:.ctor () (8 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.NonRandomizedStringEqualityComparer/OrdinalIgnoreCaseComparer:.ctor (System.Collections.Generic.IEqualityComparer`1<string>) (8 byte(s)) dotnet.native.js:1345:16
Generating System.Collections.Generic.NonRandomizedStringEqualityComparer:GetStringComparer (object) (44 byte(s)) dotnet.native.js:1345:16

We already compute the length of the appcontext arguments when converting them to UTF-16, at least in mono, so this PR switches to a 5-argument variant of Setup that accepts an array of lengths, so it can use a simpler/faster string constructor overload.

A lot of this code may get pulled in later by user code or library code in i.e. Blazor, but this ideally lets us get much further into app startup before that happens, at which point important network requests or background operations may have started instead of being blocked on the creation of AppContext.

[kg]

Pinging stephen since github suggested him. I'd love to get your thoughts or thoughts from one of Dictionary's other maintainers on the right way to perform this startup optimization without lowering our code quality. I tried a few things before arriving at this current solution.

[jkotas]

A lot of this code may get pulled in later by user code or library code in i.e. Blazor, but this ideally lets us get much further into app startup before that happens, at which point important network requests or background operations may have started instead of being blocked on the creation of AppContext.

How many methods execute in a typical Blazor app before network or background operations start?

[kg]

A lot of this code may get pulled in later by user code or library code in i.e. Blazor, but this ideally lets us get much further into app startup before that happens, at which point important network requests or background operations may have started instead of being blocked on the creation of AppContext.

How many methods execute in a typical Blazor app before network or background operations start?

I don't have a way to measure that right now, I'm still working on getting a blazor app to start with a modified runtime build. For a simple blazor-less mono-wasm application, before I started working on this we were looking at around 850 different methods having code generated, and it's around 710 with my current fix set, and I have a theory for how to prune another 50 or so from that by making static constructors cheaper.

From what I've seen in profiles of aot'd blazor my guess is it's probably in the neighborhood of 5000 methods or more. The question is whether we can move enough stuff later in startup for apps to realistically kick off network traffic, I'll have a better sense of that once I get blazor working with my local runtime binaries so I can get dense logs of method compile order.

The impact of this class of optimization is probably much smaller for AOT startup.

[kg]

Should I change this in coreclr too? It looks like corhost.cpp calls this Setup method as well.

Dictionary.cs change was reverted

[jkotas]

Should I change this in coreclr too? It looks like corhost.cpp calls this Setup method as well.

I do not think that the managed wcslen is a big deal on CoreCLR (it is expected to be r2r precompiled). Also, the string sizes are not readily available in CoreCLR.

For CoreCLR, I would pass the UTF8 key/value pairs to the managed side directly to create the managed strings without creating the intermediate copies. It would require more significant refactoring.

[kg]

Should I change this in coreclr too? It looks like corhost.cpp calls this Setup method as well.

I do not think that the managed wcslen is a big deal on CoreCLR (it is expected to be r2r precompiled). Also, the string sizes are not readily available in CoreCLR.

For CoreCLR, I would pass the UTF8 key/value pairs to the managed side directly to create the managed strings without creating the intermediate copies. It would require more significant refactoring.

OK, if it's already there then we aren't improving things by allowing it to be trimmed. Thanks for the context.