Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
/coreclrPublic archive

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

Merged
adamsitnik merged 2 commits intodotnet:masterfromadamsitnik:dateTimeNowPerfFix
Aug 8, 2019

Conversation

@adamsitnik
Copy link
Member

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

I started with reading the source code ofFileTimeToSystemTime andRtlpTimeToTimeFields methods. TheRtlpTimeToTimeFields 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 byDateTime.UtcNow I was able to make it 5% faster. It ain't much, but that's all I could do.

Before:

obraz

After:

obraz

[Benchmark]publicDateTimeOffsetGetUtcNow()=>DateTimeOffset.UtcNow;[Benchmark]publicDateTimeGetUtcNow()=>DateTime.UtcNow;
TypeMethodToolchainMeanRatio
Perf_DateTimeGetUtcNow\after\CoreRun.exe67.25 ns0.95
Perf_DateTimeGetUtcNow\before\CoreRun.exe70.75 ns1.00
Perf_DateTimeOffsetGetUtcNow\after\CoreRun.exe80.81 ns0.97
Perf_DateTimeOffsetGetUtcNow\before\CoreRun.exe83.27 ns1.00

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

/cc @danmosemsft

…ap second performance regression impact, related to #25728
Copy link
Member

@gfoidlgfoidl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Some more micro-optimizations.

@adamsitnik
Copy link
MemberAuthor

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

@adamsitnikadamsitnik merged commit4450e5c intodotnet:masterAug 8, 2019
@adamsitnikadamsitnik deleted the dateTimeNowPerfFix branchAugust 8, 2019 15:50
@danmoseley
Copy link
Member

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

adamsitnik reacted with thumbs up emoji

@tarekgh
Copy link
Member

May be it is worth to track this for 3.1?

adamsitnik reacted with thumbs up emoji

@danmoseley
Copy link
Member

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.

adamsitnik reacted with thumbs up emoji

@tarekgh
Copy link
Member

@danmosemsft thanks for the clarification.

picenka21 pushed a commit to picenka21/runtime that referenced this pull requestFeb 18, 2022
…e impact (dotnet/coreclr#26046)* make few methods used by DateTime.UtcNow inlinable to minimize the leap second performance regression impact, related to dotnet/coreclr#25728* apply suggested micro-optimizationsCommit migrated fromdotnet/coreclr@4450e5c
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

6 more reviewers

@EgorBoEgorBoEgorBo left review comments

@gfoidlgfoidlgfoidl left review comments

@danmoseleydanmoseleydanmoseley left review comments

@jkotasjkotasjkotas left review comments

@mikednmikednmikedn left review comments

@tarekghtarekghtarekgh approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@adamsitnik@danmoseley@tarekgh@EgorBo@gfoidl@jkotas@mikedn

[8]ページ先頭

©2009-2025 Movatter.jp