3 ms·
Of course. In the article linked above: > ContinueWith allocates more than using async await Does LINQ not carry a similar overhead?
by mrkeen 3y ago
Of course.
In the article linked above:
> ContinueWith allocates more than using async await
Does LINQ not carry a similar overhead?
- pjc50 3y agoYou said, "So does C# not have map yet?", knowing full well that it did, and are now moving the goalposts.
- mrkeen 3y agoI'll rephrase. Does LINQ's map come with a plethora of problems like I'm told Task's map does above? Should you avoid mapping because 'it's the old callback model' which doesn't belong in modern code? Is map fit for purpose, or has it been disavowed?
- pjc50 3y agoMapping (spelt "Select" quite often in LINQ) is entirely normal and promoted going forwards. It can optimize extremely well for simple cases. By default it is not parallel and compiles to an underlying for loop. Or you can use it with Tasks. https://itnext.io/fun-csharp-doing-linq-to-tasks-because-task-is-a-monad-2fd87a310a03 https://itnext.io/fun-csharp-doing-linq-to-tasks-because-tas... (caution: contains the M word) More from Microsoft: https://devblogs.microsoft.com/pfxteam/tasks-monads-and-linq/ https://devblogs.microsoft.com/pfxteam/tasks-monads-and-linq... ; referencing Lippert https://ericlippert.com/category/monads/ https://ericlippert.com/category/monads/ ContinueWith is not a broken "map". What people usually want is Select. https://learn.microsoft.com/en-us/dotnet/csharp/linq/standard-query-operators/projection-operations https://learn.microsoft.com/en-us/dotnet/csharp/linq/standar...