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.
Add dynamic controller/page routes #8955
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
Add dynamic controller/page routes #8955
Changes from all commits
abe960b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
ValueTask
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.
Why? Is the guidance to just use ValueTask everywhere now?
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.
I am aware that you most probably know this, and your question is partially rhetoric, but..
I think the guidance (as of "Stephen Toub says so") is that if the method is mostly expected to return synchronously (like in a "streaming over bytes that are most of the time in memory but rarely have to be fetched over the wire" scenario), use a ValueTask, but if the method is expected to do real async work reasonably often (like let's say > 20% of the time, I'm not sure where I got this number from, but it stuck) use Task, as ValueTask comes with it's own struct-based overhead and just wraps a real Task in that case..
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.
ValueTask<T>
is still the guidance, there's almost no reason to useTask<T>
as it forces an allocation. You can also now reuse allocations withValueTask<T>
so it's an extensibility point as well.Yes, generic
ValueTask<T>
absolutely, forValueTask
is more questionable and has more overhead and is only really valuable as an extensibility point (usingIValueTaskSource
)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.
hrm didn't sound like it here: https://devblogs.microsoft.com/dotnet/understanding-the-whys-whats-and-whens-of-valuetask/#user-content-should-every-new-asynchronous-api-return-valuetask--valuetasktresult
"In short, no: the default choice is still Task / Task."
...
" There are also some minor costs associated with returning a ValueTask instead of a Task, e.g. in microbenchmarks it’s a bit faster to await a Task than it is to await a ValueTask, so if you can use cached tasks (e.g. you’re API returns Task or Task), you might be better off performance-wise sticking with Task and Task. ValueTask / ValueTask are also multiple words in size, and so when these are awaitd and a field for them is stored in a calling async method’s state machine, they’ll take up a little more space in that state machine object."
Honstely that#s a bit over my head though... back then I read "use ValueTask only when it completes mosty synchronous" out of it
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.
If you have a virtual member, you can't assume what derived implementations will do. To optimize for common synchronous cases and offer extensibility for derived types, use
ValueTask<T>
.The framework is the one that is awaiting this so it's mostly up to the implementation to just return synchronously or asynchronously. The other downsides don't apply.
I really want to go back the change a bunch of APIs to return
ValueTask<T>
😄 . I could squash so many needless allocations in the auth stack..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.
Appreciate the time you took to answer that. Hopefully someone finds this hidden conversation, reads it and learns, too.