Optimize System.DateTime

[pentp]

Makes DateTime.UtcNow about 5% faster (over 90% time is spent in OS calls now).
Also changed most of DateTime calculations to use unsigned integers.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

Related to #44771

[jkotas]

I do not think it is worth optimizing these using ThrowHelper.

[pentp]

This isn't an optimization but just reducing code size/duplication.

[tarekgh]

@pentp I am off properly will not be able to go deeper in this review. I am seeing you are touching the leap seconds handling in the code and I am not sure if the changes would affect that. did you test with a leap seconds on in any system?

[tarekgh]

@jkotas would be good to not merge this till it is carefully reviewed and tested with leap seconds.

[jkotas]

@jkotas would be good to not merge this till it is carefully reviewed and tested with leap seconds.

Agree. I won't merge this before you and @GrabYourPitchforks sign off on this.

[ViktorHofer]

// Auto-generated message

69e114c which was merged 12/7 removed the intermediate src/coreclr/src/ folder. This PR needs to be updated as it touches files in that directory which causes conflicts.

To update your commits you can use this bash script: https://gist.github.com/ViktorHofer/6d24f62abdcddb518b4966ead5ef3783. Feel free to use the comment section of the gist to improve the script for others.

[jkotas]

@pentp I have deleted the DateTime FCalls in #46690 that will make this delta smaller. Could you please resolve the conflict?

[tarekgh]

Hi @pentp, do you have a chance to resolve the merge conflict?

[pentp]

Yes, I'll rebase and fix the conflicts.
I've thought about how to write tests for the leap second paths also and now that the native part has been removed it should be possible to use function pointers in checked builds for TzSpecificLocalTimeToSystemTime/SystemTimeToFileTime (like s_pfnGetSystemTimeAsFileTime) and then write tests that intercept these calls so that IsValidTimeWithLeapSeconds can return a predetermined value. Alternatively, the entire IsValidTimeWithLeapSeconds call could be intercepted (perf less important as it should be a rare call). Does that sound like something worth investigating?

[tarekgh]

@pentp

Yes, I'll rebase and fix the conflicts.

Thanks a lot.

I've thought about how to write tests for the leap second paths also and now that the native part has been removed it should be possible to use function pointers in checked builds for TzSpecificLocalTimeToSystemTime/SystemTimeToFileTime (like s_pfnGetSystemTimeAsFileTime) and then write tests that intercept these calls so that IsValidTimeWithLeapSeconds can return a predetermined value. Alternatively, the entire IsValidTimeWithLeapSeconds call could be intercepted (perf less important as it should be a rare call). Does that sound like something worth investigating?

I didn't closely review your original changes so I am not clear why need to intercept the calls to IsValidTimeWithLeapSeconds? is it part of the optimization we are trying to do here? or this is just to do some validation? If this is not related to the optimization, then I would say let's focus to get the optimization first and have some perf numbers how much we are gaining.

[tarekgh]

@pentp sorry to ping you again. Would you be able to get this soon? I am asking because we are trying to close long opened PR's. Thanks!

[pentp]

Rebased and resolved conflicts. Test failures seem to be #47374.

[tarekgh]

Thanks @pentp. I'll take a look soon.

[tarekgh]

@pentp thanks a lot. The changes LGTM. As it looks this changes will give us some perf gain. do we have some perf numbers for that. (at least in the basic scenarios with DateTime)?

[pentp]

For DateTime.UtcNow it's about 6% faster (x64 asm size from 625 to 413), DateTime.Now is about 10% faster, TryParseExact for round-trip format O is about 4% faster (uses DatetTime.TryCreate).
The other methods I haven't measured properly, but they all have reduced asm code size.

[mattjohnsonpint]

I got through about half of this so far, and will review further tomorrow.

[tarekgh]

@pentp did you have time to address the remaining comments? I think we should be good to go after that.

[tarekgh]

@pentp thanks for getting this done. this is amazing.

[tarekgh]

#45318