make DateTime.UtcNow 5% faster to minimize the leap second performance impact

[adamsitnik]

Today I've again profiled #25728 and was looking for some ways of lowering the regression.

I started with reading the source code of FileTimeToSystemTime and RtlpTimeToTimeFields methods. The RtlpTimeToTimeFields takes care of leap second support, it knows all leap seconds and knows how to handle the positive and negative ones. Copying this logic from OS to .NET makes obviously no sense, it's too complex and too expensive to maintain.

By inlining some small methods that are called by DateTime.UtcNow I was able to make it 5% faster. It ain't much, but that's all I could do.

Before:

After:

[Benchmark]
public DateTimeOffset GetUtcNow() => DateTimeOffset.UtcNow;

[Benchmark]
public DateTime GetUtcNow() => DateTime.UtcNow;

Type	Method	Toolchain	Mean	Ratio
Perf_DateTime	GetUtcNow	\after\CoreRun.exe	67.25 ns	0.95
Perf_DateTime	GetUtcNow	\before\CoreRun.exe	70.75 ns	1.00
Perf_DateTimeOffset	GetUtcNow	\after\CoreRun.exe	80.81 ns	0.97
Perf_DateTimeOffset	GetUtcNow	\before\CoreRun.exe	83.27 ns	1.00

And yes, all the [MethodImpl(MethodImplOptions.AggressiveInlining)] were really needed. Moving the throws to ThrowHelper was not enough to get those methods inlined.

/cc @danmosemsft

[gfoidl]

Some more micro-optimizations.

[adamsitnik]

Thanks for all the suggested micro-optimizations, I was able to improve the time by 0.5%

[danmoseley]

Given the regression from 2.2 was so much larger, my assumption is that it is not worth porting this into 3.0.

[tarekgh]

May be it is worth to track this for 3.1?

[danmoseley]

Our bar right now is a little bit lower or the same as the bar we will use for 3.1. So if we don't take it for 3.0 we would not take it for 3.1.

[tarekgh]

@danmosemsft thanks for the clarification.