1000 more types loaded in .NET 10 vs. .NET 8 during startup in a small workload

[jkotas]

Found during investigation of verbose logs shared at #120288 (comment)

Most of these extra types are loaded as side-effect of vectorization based on generic numerics.

[jkotas]

For example, #105654 was identified as contributor to the #120288 startup time regression. We need to start treating these generic tricks the same way as Linq, and avoid them in lower layers that need to be lean.

[stephentoub]

For example, #105654 was identified as contributor to the #120288 startup time regression. We need to start treating these generic tricks the same way as Linq, and avoid them in lower layers that need to be lean.

What approach would you recommend instead in that case? ie what is the fix?

[tannergooding]

@davidwrighton suggested one possible improvement would be to have them in a single generic class rather than having each method be generic.

i.e. we have 60+ generic methods in the System.Number internal class, these could instead be in System.Number.Nested<T> or System.Number<T> which would help reduce the number of type loads required. It doesn't, however, alleviate it entirely and it is a little bit of a tradeoff

There's potentially some VM work that could be done to mitigate the costs as well.

---

I don't like the idea of us having to completely avoid these in the primitive types. They are being used to avoid duplicating thousands of lines of complex code between the UTF-8 and UTF-16 or similar paths.

We are similarly using them in places like MemoryExtensions to avoid duplicating logic across the V128, V256, and V512 code paths to ensure we get the right performance without the additional risk and had been planning on utilizing similar tricks as part of the unsafe reduction effort, because we had significant success when applying such patterns for System.Numerics.Tensors.TensorPrimitives and friends.

Ideally we do mitigate this as much as possible in the VM and find some good patterns (such as using generic types) to help reduce the number of type loads so we don't need to duplicate the complex code.

[jkotas]

Low-tech solution is to make it work like C++ templates: create specializations at build time like what we used to do before numeric generic interfaces were invented so that the runtime sees a straightforward code and avoids type explosions to figure things out. It can be automated using source generators or tools ala T4 to avoid duplication of checked in code.

We can also attempt to do more type loader magic to avoid the type explosion produced by these patterns. It is getting very complicated and it is hard to be lazy when the things are actually used. We have done one pass on loading the numeric interfaces lazily to avoid the startup performance regression when the numeric interfaces were introduced originally.

[jkotas]

We are similarly using them in places like MemoryExtensions to avoid duplicating logic across the V128, V256, and V512 code paths to ensure we get the right performance without the additional risk and had been planning on utilizing similar tricks as part of the unsafe reduction effort, because we had significant success when applying such patterns for System.Numerics.Tensors.TensorPrimitives and friends.

It is ok for System.Numerics.Tensors.TensorPrimitives to be as heavy as Linq.

I am not convinced that the approach that we have been using in TensorPrimitives is the right way to do safe vectorization.

[davidwrighton]

I was looking at the code which triggered the extra loads and we may be able to make a fairly simple change in the loader. I'll look into it on Monday

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.