How does reflection work in .NET and what does it cost? Explain Type, MemberInfo and BindingFlags, why MethodInfo.Invoke is slow, how to make reflection fast (cached delegates, MethodInvoker in .NET 8, UnsafeAccessor), and why reflection breaks trimming and Native AOT unless you annotate it.

How I would answer this in an interview

Reflection lets code inspect and use type metadata at run time: discover types, members and attributes, create instances, read/write properties and invoke methods by name. It's how DI containers, serialisers, ORMs, test frameworks and model binding historically worked. It's powerful but slow when used naively, and it fundamentally conflicts with trimming and NativeAOT, because the tools can't see which members you'll access by name at run time.

1. The building blocks

Type t = typeof(Order);                          // or obj.GetType(), Type.GetType("Ns.Order, Assembly")
PropertyInfo? total = t.GetProperty("Total", BindingFlags.Public | BindingFlags.Instance);
MethodInfo? submit = t.GetMethod("Submit");
ConstructorInfo? ctor = t.GetConstructor([typeof(Guid)]);

object order = ctor!.Invoke([Guid.NewGuid()]);
decimal value = (decimal)total!.GetValue(order)!;
submit!.Invoke(order, null);

var attrs = t.GetCustomAttributes<AuditedAttribute>();

• Type: the entry point (IsClass, IsGenericType, GetInterfaces(), BaseType, GetGenericArguments()).
• MemberInfo hierarchy: FieldInfo, PropertyInfo, MethodInfo, ConstructorInfo, EventInfo.
• BindingFlags: filters — Public/NonPublic, Instance/Static, DeclaredOnly, IgnoreCase, FlattenHierarchy. Forgetting Instance or Static returns nothing (a common bug).
• Assembly: GetTypes(), GetExportedTypes(), used for scanning (registering handlers).

2. Why MethodInfo.Invoke is slow

A direct call is a few nanoseconds. Invoke historically took hundreds of nanoseconds or more because it:

• validates arguments and the target type,
• allocates an object[] for arguments and boxes value-type arguments and return values,
• performs security/accessibility checks,
• goes through a generic invocation stub (unless the runtime generates an optimised one after repeated calls),
• wraps exceptions in TargetInvocationException.

Lookups themselves (GetProperty, GetMethod, GetCustomAttributes) also cost string comparisons and allocations — cache MemberInfo objects.

.NET 7/8 made reflection invocation much faster (emitting IL stubs after a few calls), but it's still far slower than direct calls and allocates.

3. Making reflection fast

1. Cache Type/MemberInfo lookups (static dictionaries or generic static caches).
2. Create delegates once and call them:

var getter = (Func<Order, decimal>)Delegate.CreateDelegate(typeof(Func<Order, decimal>), total!.GetGetMethod()!);
decimal v = getter(order);   // near-direct speed

(Or compile expression trees once — but that needs runtime code generation.) 3. MethodInvoker / ConstructorInvoker (.NET 8): MethodInvoker.Create(methodInfo) gives a reusable invoker with overloads that avoid object[] allocation for up to four arguments and skip repeated validation. 4. UnsafeAccessor (.NET 8): declare an extern method with [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_secret")] and the runtime binds it directly to a private member — no reflection at run time, AOT- and trim-friendly, essentially direct-call speed. Great for serialisers and tests needing private access (use sparingly; it bypasses encapsulation). 5. Best of all, source generators that write the code at compile time (System.Text.Json source generation, logging, DI registration).

4. Why reflection breaks trimming and NativeAOT

• Trimming (ILLink) removes unused types and members by static analysis. If code does Type.GetType("MyApp.Plugins." + name) or GetProperty(propertyName), the trimmer can't know what's needed and may remove it → null/MissingMethodException at run time.
• NativeAOT compiles everything ahead of time: no JIT, so Reflection.Emit, Expression.Compile() (falls back to interpretation), and MakeGenericType with unknown value-type instantiations may fail or be slow.
• The SDK reports trim/AOT warnings (IL2026, IL2070, IL2075, IL3050) for reflection that can't be analysed.

Annotate to make reflection analysable:

public static object Create([DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] Type type)
    => Activator.CreateInstance(type)!;

[RequiresUnreferencedCode("Uses reflection over arbitrary types")]
[RequiresDynamicCode("Builds generic types at run time")]
public static void LegacyScan(...) { ... }

[DynamicallyAccessedMembers] tells the trimmer to keep certain members of types flowing into that parameter; [RequiresUnreferencedCode]/[RequiresDynamicCode] propagate warnings to callers; [DynamicDependency] keeps specific members. Ultimately, the AOT-friendly approach is to replace runtime reflection with compile-time generation.

5. A production example

A custom mapper used PropertyInfo.GetValue/SetValue per property per object, mapping millions of rows in a nightly job; profiling showed most CPU in reflection and boxing. Caching compiled getter/setter delegates per type cut the job time by ~80%. Later, moving the API to NativeAOT surfaced IL2075 warnings for the mapper; we replaced it with Mapperly (source-generated), which removed both the reflection cost and the AOT warnings.