Understanding how to use Task and ValueTask
HTML-код
- Опубликовано: 12 сен 2024
- Understanding the Whys, what’s, and when’s of ValueTask
devblogs.micro...
ValueTask reference docs
docs.microsoft...
NuGet package for ValueTask
www.nuget.org/...
In this episode, Stephen Toub chats with Rich about ValueTask and how it might help reduce allocations and memory usage for your asynchronous .NET code.
[00:34] - What is ValueTask and why do we need it?
[05:22] - What is a good scenario for ValueTask?
[10:00] - What is IValueTask?
[12:14] - Why was the non-generic ValueTask introduced?
[13:54] - Does ValueTask offer cancellation?
[14:42] - What can you do with Task vs ValueTask?
[16:28] - What’s the uptake with ValueTask usage?
[18:28] - How does IAsyncEnumerable task advantage of ValueTask?
[21:11] - What other performance work is happening around allocations?
I generally learn most from these when you have some code examples to go along with the discussion. It's very difficult to understand the examples without any reference. Consider doing another video with the various code scenarios Rich has provided (there are many!).
I agree. You might like this video: ruclips.net/video/nK54s84xRRs/видео.html
@@AdamsTaiwan I had just went through the video and was going to mentioned it. The presentation by Matt is excellent!
Amazing stuff!
This is the kind of topic you have to watch and re-watch a few times to grasp very well.
I have read the blog post previously and the video helped a lot to understand some grey areas that I haven't understand properly.
The video probably would be 1h long or more to talk through everything.
Thanks again!
This is exactly what I needed haha, thanks for the great content as always!
Hi, Can you guys do a comparative analysis on Memory and T [ ] ?
I subscribed! Nice video and very informative
How can the data be already there without a cache? If I make the same httpcall twice, the call will be async both times, will it not?
Task results are cached for all threads within an application domain, so the result is the same/shared for all of them. What he is addressing, specifically, is reading from a file into memory, and the initial read from the file might take some time, thus cause a task to be awaited and thus allocated onto the heap, but that task reads the entire file, meanwhile on the client the file is processed inside of a loop that reads from that file read result in chunks…so, the file contents are all in RAM. Those task will evaluate even before you “await” it, aka. sync, and thus not have to be allocated to the heap for continuation, but because they are a class they have already been allocated onto the heap. In these types of cases, a ValueTask struct is better, since it is on the stack (vs the heap) and thus no heap allocation occurs. HOWEVER, there is a gotcha. If you use a ValueTask, and it doesnt complete before it is Awaited, it has to be boxed AND allocated on the heap, making it slower than a regular task that would have already been boxed and allocated. An awaited struct that has to be converted into a task for heap allocation actually is worse than a Task. Look into the AsyncTaskMethodBuilder class and the AwaitOnCompleted method. I’ve created a custom task that actually uses collected telemetry, for a specific Caller method, to determine whether it should return a ValueTask or Task.
Would like to see more examples. I have an app that takes a snapshot of folders/files(with hash codes) on an external drive, saves it to a DataSet then saves it to file or DB. To update I have 2 passes , first pass looks for files in the dataset that have been removed. Second pass checks file system for new or modified files.
When I don't have access to the external drive, I can load the DataSet and perform searches or check to see if a set of files on my local drive exist in the DataSet.
I'm looking for ways to speed up the process wherever I can.
Retrieve that data from the disk and/or DB using Task,and create a reference to that completed task(like a property) Repeated references to a completed task will not re-execute the task when you await it more than once. Completed task can’t be restarted or re-run without explicit redeclaration. A valuetask might be used to parse the first tasks result in chunks, but a sync method will probably be easier, given that the first task is completed and result now local.
I don't understand, why provide an Async method that returns ValueTask if you know it's always going to return Synchronously? Why not just use a synchronous method instead.
Imagine your ValueTask is run 99% sync and 1% async. for example you read a file once and after that others use it synchronously, you may not want to block your thread for that 1% time.
to prevent blocking, just in case. Also, generally, an application is either all async or sync. Mixing them is, of course, possible, but most people dont have the low level knowledge to do it. In actually, a Task is a wrapper for a sync method call. It is using the ThreadPool.QueneWorkItem. ;)
Oh I get it, so ValueTask means value/vask, not a value (type) task :\
I was damn confused about this name for a while
Yeah, not value type return, but ByVal Task. That is, a struct and not a task. ;)
Multi Value Tasks.
Marc Gravel of StackOverflow disagrees, "Prefer ValueTask to Task": blog.marcgravell.com/2019/08/prefer-valuetask-to-task-always-and.html
That blog post did not consider all edge cases (e.g. `Task.WaitAny/WaitAll`, unknown `IValueTaskSource` implementation). And even with it's narrow analysis, conclusion is lame "always use, even when breaking API, but don't await twice". I'm sure Stephen Toub who wrote most of the TPL and `ValueTask` knows a bit more about the topic.
Steven created the Task and ValueTask model. Trust me, and him, he’s correct in his information expressed here. If you look at the lowered code, it confirms his statements. ValueTask is useful, for sure, but it’s not a replacement for a .NET Task. There are, however, better implementations for a unit of work, but you have to create your own custom task-like construct, and I dont recommend doing that unless you are REALLY good at C and C#. The issues he’s discussing here, and what you’ll find in creating custom tasks, are constraints of stack-based computers (turing machines) and he doesnt even discuss other issues like context switching and execution context. There’s a lot involved he’s not mentioning, but is fully aware of.