-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microsoft.Extensions.Caching.Memory.MemoryCache: Reduce DateTime.UtcNow calls #36775
Microsoft.Extensions.Caching.Memory.MemoryCache: Reduce DateTime.UtcNow calls #36775
Conversation
In a few MemoryCache hot paths, we're doing a syscall to get the time twice. It's far from ideal since the cost is a significant portion of the overall time. This is step 1, minor and non-breaking for ~30% gains in performance.
What's needed to poke the remaining builds here? Is it something someone can kick please? |
That was easy 😄 |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for the contribution!
Actually, looks like a conflict came in. @NickCraver can you resolve, please? |
Nifty, GitHub web editor let me resolve this. Kudos github. |
Hello @ericstj! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Guessing that run isn't going to finish?
|
In a few
Microsoft.Extensions.Caching.Memory.MemoryCache
hot paths, we're doing a syscall to get the current time twice. It's far from ideal since the cost is a significant portion of the overall time. This is step 1, minor and non-breaking for a ~30% gain in performance. The current 2 time calls are:It turns out
DateTime.UtcNow
is quite expensive since .NET Core 3.x (details in #13091) - in doing benchmarks on memory cache (honestly more for allocation reasons), we noticed the overhead here.Simple benchmarks (will PR to
dotnet/performance
) at: MemoryCacheTests.csBefore PR
After PR
This is a hopefully low-contention first pass at a cheap win in
MemoryCache
. A follow-up (I'll open a global issue) would be to not callStartScanForExpiredItems
in the hot path, and instead move the cleanup process to a background timer. I'll fire up an issue to discuss those other follow-ups.