This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Use new threading-related APIs in Channels to improve throughput #33080
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stephentoub
commented
Oct 26, 2018
tarekgh
approved these changes
Oct 27, 2018
ericstj
reviewed
Oct 27, 2018
| @@ -3,6 +3,7 @@ | |||
| <PropertyGroup> | |||
| <BuildConfigurations> | |||
| netstandard; | |||
| netcoreapp; | |||
There was a problem hiding this comment.
Curious why you added this since the test doesn't differ.
There was a problem hiding this comment.
I'll remove that. It's left over from when I actually was adding/testing APIs.
ericstj
approved these changes
Oct 27, 2018
- Avoid ThreadPool-related allocations via IThreadPoolWorkItem. We already had a fairly low allocation profile on most channels, thanks to an IValueTaskSource implementation. This extends that implementation with an IThreadPoolWorkItem implementation so that when we do need to queue to the pool (e.g. to support RunContinuationsAsynchronously, on writes on the bounded queue, etc.), we can do so without incurring additional allocation. - Avoid ExecutionContext costs with CancellationToken.UnsafeRegister. Minor savings when a cancelable token is provided; we don't need to flow context as all we're doing is completing another object.
0d0758a to
c0acccf
Compare
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
- Avoid ThreadPool-related allocations via IThreadPoolWorkItem. We already had a fairly low allocation profile on most channels, thanks to an IValueTaskSource implementation. This extends that implementation with an IThreadPoolWorkItem implementation so that when we do need to queue to the pool (e.g. to support RunContinuationsAsynchronously, on writes on the bounded queue, etc.), we can do so without incurring additional allocation. - Avoid ExecutionContext costs with CancellationToken.UnsafeRegister. Minor savings when a cancelable token is provided; we don't need to flow context as all we're doing is completing another object. Commit migrated from dotnet/corefx@89ab1e8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On a microbenchmark that tests the throughput of writing to a full bounded channel (e.g. where every write blocks, then a read unblocks it, rinse and repeat), this improves throughput by ~20%, primarily due to the decreased allocation for the queued work items.
cc: @tarekgh
(This replaces #32904. I dropped the new APIs, as the right implementation requires compiler support from a compiler we don't yet have, and I'll do those separately later).