Optimizing alternatives to DateTime.Now

Question

A colleague and I are going back and forth on this issue and I\'m hoping to get some outside opinions as to whether or not my proposed solution is a good idea.

First

Answer 1

I like your solution. I made some tests to see how much faster it is compared to regular DateTime.Now

DateTime.UtcNow is 117 times faster than DateTime.Now

using DateTime.UtcNow is good enough if we are only interested in the duration and not the time itself. If all we need is to calculate the duration of a specific code section ( doing duration= End_time - Start_time ) then the time zone is not important and DateTime.UtcNow is sufficient.

But if we need the time itself then we need to do DateTime.UtcNow + LocalUtcOffset

Just adding the time span slows down a little bit and now according to my tests we are just 49 times faster than the regular DateTime.Now

If we put this calculation in a separate function/class as suggested then calling the method slows us down even more and we are only 34 times faster.

But even 34 times faster is a lot !!!

In short, Using DateTime.UtcNowis much faster than DateTime.Now

The only way I found to improve the suggested class is to use inline code: DateTime.UtcNow + LocalUtcOffset instead of calling the class method

BTW trying to force the compiler to compile as inline by using [MethodImpl(MethodImplOptions.AggressiveInlining)] didnt seem to speed things up.