As always you should benchmark your own use cases and don't make the same mistakes I made below when doing so...

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1566 (21H2)
Intel Core i7-10610U CPU 1.80GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.200
  [Host]     : .NET 6.0.2 (6.0.222.6406), X64 RyuJIT
  DefaultJob : .NET 6.0.2 (6.0.222.6406), X64 RyuJIT

Originally this was a long winded post about how the "simplest" option:

if (_logger.IsEnabled(LogLevel.Information))
{
    _logger.LogInformation(Message, Parameter1, Parameter2, Parameter3, Parameter4, Parameter5, Parameter6);
}

Was significantly faster when dynamic log parameters were involved. All benchmarks I had seen previously were logging constant values and I decided I wanted to represent the "real" world use case with parameters that changed between calls (TLDR; it's a benchmark not the real world):

public DateTime Parameter1 => DateTime.UtcNow;

public Guid Parameter2 => Guid.NewGuid();

public int Parameter3 => Random.Shared.Next();
...

What I didn't expect was that moving the "simple" that logic into an extension would be significantly slower (TLDR; it's not):

_logger.Information(Message, Parameter1, Parameter2, Parameter3, Parameter4, Parameter5, Parameter6);

public static void Information<T1, T2, T3, T4, T5, T6>(this ILogger logger, string message, T1 parameter1, T2 parameter2, T3 parameter3, T4 parameter4, T5 parameter5, T6 parameter6)
{
    if (logger.IsEnabled(LogLevel.Information))
    {
        logger.LogInformation(message, parameter1, parameter2, parameter3, parameter4, parameter5, parameter6);
    }
}

I spent a good portion of the day trying to figure out the reasoning behind this significant time difference in my benchmark. I had all these fanicful ideas of how the compiler/runtime were optimizing away the simple check but couldn't quite understand why.

It got to the point where I was having BenchmarkDotNet record the generated assembly code from the benchmarks. While painfully trying to decrypt that I saw my first clue as to the cause, a call to UpdateLeapYearCache (or something similar) when the extension method was accessing the DateTime parameter.

Being convinced the problem was not in how I had implemented my benchmark but something else entirely I (ridiculously) decided (based on nothing) that DateTime.UtcNow was slow and while I'm at it Guid.NewGuid() is probably slow too so lets swap those all to Random.Shared.Next() calls because that has to be fast 🙄

In case you haven't caught it yet I had neglected the fact that if my property getter is generating a new value then that is work that will add to the overhead of the benchmark. I was so focused on what I thought was the problem that I missed the fact that in the "simplest" option I was executing a conditional check before accessing the property getters and in every other implementation I had to access them prior executing the check.

At least I wasn't crazy 😉

My takeaways/reminders from the day are:

• Be willing to consider that your initial assumption may be wrong
• Keep benchmarks targeted and consistent across runs

In any case maybe you'll learn something from my mistake or find use in this code if you want to bootstrap your own logging benchmarks...