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

/benchmark micro aspnet-perf-win runtime --variable filter=System.Tests.Perf_Array

/benchmark micro aspnet-perf-win runtime --variable filter=System.Tests.Perf_Enum

/benchmark micro aspnet-perf-win runtime --variable filter=System.Reflection.Activator

Benchmark started for micro on aspnet-perf-win with runtime and arguments --variable filter=*System.Reflection.Activator*. Logs: link

Benchmark started for micro on aspnet-perf-win with runtime and arguments --variable filter=*System.Tests.Perf_Enum*. Logs: link

I have run this micro-benchmark on Win x64 to see the perf of composite cache:

using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;

var sw = new Stopwatch();
for (;;)
{
   sw.Restart();
   Work();
   Internal.Console.WriteLine(sw.ElapsedMilliseconds.ToString());
}

static void Work()
{
    for (int i = 0; i < 100000000; i++)
    {
        GC.KeepAlive(Activator.CreateInstance(typeof(object)));
        GC.KeepAlive(RuntimeHelpers.GetUninitializedObject(typeof(object)));
    }
}

It runs about 1.3x-1.4x slower compared to current main. These seems to be a lot of perf lost in the generics. Can we do better?

I'll see if I can make it faster.

I've been focusing on matching performance with our existing (single-entry-focused) microbenchmarks. I've been able to get within single-digit percentage (even with a possible improvement in one run) for Activator.CreateInstance. I'll spend some time on the composite case.

I have tried to replace the InlineArray with explicit fields jkotas@1a96a78 . It fixed the perf for my micro-benchmark. (The change is not complete - it is missing handling of EnumInfo.)

@jkotas can you take one last review pass on this? Looks like Build Analysis is green so it’s ready to merge once it’s approved.