.NET Reflection Benchmarks: Enum Attribute Performance (Part 1)

.NET reflection has a reputation for being slow, hard to read and something to avoid. But does this still apply in newer .NET versions like .NET 8+?

When I was a junior developer, I often heard that reflection should not be used, just avoid it. Over time, I encountered many scenarios where reflection was not only convenient, but also the most maintainable solution.

In this series, I’ll benchmark common reflection use cases to understand its real performance characteristics and trade-offs. The goal is simple: separate myths from measurable cost.

In this first part, we focus on a very common scenario, retrieving custom attributes from enum values and compare reflection against alternatives such as Dictionary and FrozenDictionary.

Get Custom Attribute

Sometimes we need human-readable descriptions for enum values, and one of the simplest approaches is to use attributes. Reflection provides a convenient way to retrieve these attributes at runtime.

In this benchmark, we evaluate the performance of a generic extension method that retrieves custom attributes from enum values.

Reflection Implementation

A basic extension method for retrieving a custom attribute from an enum looks like this:

public static class EnumExtensions
{
    public static T GetCustomAttribute<T>(this Enum customEnumValue) where T : Attribute
    {
        var enumType = customEnumValue.GetType();
        return enumType
            .GetField(Enum.GetName(enumType, customEnumValue)!)!
            .GetCustomAttribute<T>()!;
    }
}

Since we are creating a benchmark, we should also implement a more performant version. We can improve performance by caching results using a ConcurrentDictionary:

public static class EnumExtensions
{
    private static readonly ConcurrentDictionary<(Type EnumType, Type AttributeType, string MemberName), Attribute?> _cache = new();

    public static T? GetCustomAttributeCached<T>(this Enum customEnumValue) where T : Attribute
    {
        var enumType = customEnumValue.GetType();
        var key = (enumType, typeof(T), Enum.GetName(enumType, customEnumValue)!);
        return (T?)_cache.GetOrAdd(key, static k =>
            k.EnumType.GetField(k.MemberName)?.GetCustomAttribute(k.AttributeType));
    }
}

Note: ConcurrentDictionary is used here to ensure thread-safe access, as this extension method may be called concurrently from multiple threads.

Dictionary-Based Alternative

To compare against a faster alternative, I created a static dictionary that maps CustomEnum values to their corresponding descriptions:

public static class CustomEnumMap
{
    public static readonly Dictionary<CustomEnum, string> Map = new Dictionary<CustomEnum, string>()
    {
        ...
    };
}

Starting with .NET 8, we can use FrozenDictionary, which is optimized for read-heavy, write-once scenarios. This allows us to compare it with a standard Dictionary.

public static readonly FrozenDictionary<CustomSmallEnum, string> FrozenSmallMap = Map.ToFrozenDictionary();

Note: Another possible approach is to use a source generator, which can eliminate manual maintenance of mappings like FrozenDictionary. However, this comes at the cost of increased complexity and more difficult debugging. I am not covering it here, as it would likely produce performance similar to the FrozenDictionary approach.

Enum definition

To evaluate whether enum size has any impact on performance, I created three enums of different sizes:

• CustomLargeEnum with 35 values
• CustomEnum with 16 values
• CustomSmallEnum with 7 values

The CustomEnumAttribute is very simple:

[AttributeUsage(AttributeTargets.Field)]
public sealed class CustomEnumAttribute : Attribute
{
    public string Description { get; }

    public CustomEnumAttribute(string description)
    {
        Description = description;
    }

}

Benchmark code

The benchmark iterates over pre-generated arrays of random enum values and calls GetCustomAttribute for each item.

[SimpleJob(RuntimeMoniker.Net10_0)]
[Orderer(BenchmarkDotNet.Order.SummaryOrderPolicy.FastestToSlowest)]
[MemoryDiagnoser]
public class GetEnumAttributeBenchmark
{
    [Params(1,100,1000,10000)]
    public int Count;

    private CustomEnum[] _values = [];
    private CustomSmallEnum[] _smallValues = [];
    private CustomLargeEnum[] _largeValues = [];


   [GlobalSetup]
    public void Setup()
    {
            var rnd = new Random(42);

            var all = Enum.GetValues<CustomEnum>();
            var smallAll = Enum.GetValues<CustomSmallEnum>();
            var largeAll = Enum.GetValues<CustomLargeEnum>();

            _values = [.. Enumerable
                .Range(0, Count)
                .Select(_ => all[rnd.Next(all.Length)])];

            _smallValues = [.. Enumerable
                .Range(0, Count)
                .Select(_ => smallAll[rnd.Next(smallAll.Length)])];

            _largeValues = [.. Enumerable
                .Range(0, Count)
                .Select(_ => largeAll[rnd.Next(largeAll.Length)])];
    }

    [Benchmark(Baseline = true)]
    public void CustomEnum()
    {
        for (var i = 0; i < _values.Length; i++)
        {
            _ = _values[i].GetCustomAttribute<CustomEnumAttribute>().Description;
        }
    }

    [Benchmark]
    public void CustomLargeEnum()
    {
        for (var i = 0; i < _largeValues.Length; i++)
        {
            _ = _largeValues[i].GetCustomAttribute<CustomEnumAttribute>().Description;
        }
    }
    ...
}

Source Solution

Results

BenchmarkDotNet v0.15.8, Windows 10 (10.0.19045.6466/22H2/2022Update)
Intel Core i5-6400 CPU 2.70GHz (Skylake), 1 CPU, 4 logical and 4 physical cores
.NET SDK 10.0.201
  [Host]    : .NET 10.0.5 (10.0.5, 10.0.526.15411), X64 RyuJIT x86-64-v3
  .NET 10.0 : .NET 10.0.5 (10.0.5, 10.0.526.15411), X64 RyuJIT x86-64-v3

Job=.NET 10.0  Runtime=.NET 10.0

Let's start with the Count = 1 scenario.

FrozenDictionary appears to be the fastest approach, with measured times in the sub-nanosecond range. However, results at this scale should be interpreted cautiously, as they are highly sensitive to JIT optimizations.

A standard Dictionary performs consistently at around ~4.5 ns per lookup, which is still extremely fast and effectively negligible in most applications.

Cached reflection shows a significant improvement over uncached reflection, reducing execution time from ~888 ns to ~55-65 ns per call. This demonstrates that caching eliminates the majority of reflection overhead.

Uncached reflection is by far the slowest approach, with roughly 15-16x higher latency compared to cached reflection and orders of magnitude slower than dictionary-based solutions.

In terms of memory allocations:

• Dictionary-based approaches allocate no memory during lookup
• Cached reflection allocates ~24 B per call. This is caused by boxing the enum value when using the Enum type. A zero-allocation alternative is possible using a generic constraint, but it results in a more verbose API:

public static TAttribute? GetCustomAttributeCached<TEnum, TAttribute>(this TEnum value) 
    where TEnum : struct, Enum 
    where TAttribute : Attribute

• Uncached reflection allocates ~270-280 B per call

When scaling to higher Count values, the relative differences remain consistent. Execution time increases linearly for all approaches, but the absolute gap between them becomes more pronounced due to the higher per-call cost of reflection.

Finally, the size of the enum does not have a measurable impact on performance in this benchmark, which is expected given the constant-time nature of the underlying lookup mechanisms.

Summary

Dictionary-based solutions provide the best raw performance and avoid allocations during lookups, but require manual maintenance whenever enum values change. This could be avoided with source generators, which provide zero-reflection, zero-allocation, near-native performance. However, they introduce additional complexity and make debugging more difficult, which may be unnecessary for many scenarios.

Reflection is slower and introduces allocations, but when combined with caching, the performance cost becomes negligible for low-frequency operations. In many real-world scenarios, the improved maintainability outweighs the performance difference.

Reflection should therefore be avoided in hot paths but remains a practical and maintainable solution for metadata access.