runtime: ValueTask doesn't inline well
None of the method builder or methods on ValueTask seem to inline very well
Inlinee: System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.Decimal].Create - value class System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1<!0> () Fail Reason: Native estimate for function size exceeds threshold.
Inlinee: System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.Decimal].get_Task - instance value class System.Threading.Tasks.ValueTask`1<!0> () Fail Reason: Native estimate for function size exceeds threshold.
Inlinee: System.Runtime.CompilerServices.ValueTaskAwaiter`1[System.Decimal].GetResult - instance !0 () Fail Reason: Native estimate for function size exceeds threshold.
Inliner: TheAwaitingGame.Order+<GetOrderWorthValueTaskAsync>d__5.MoveNext - instance void () Inlinee: instance value class System.Threading.Tasks.ValueTask`1<value class System.Decimal> () Fail Reason: Native estimate for function size exceeds threshold.
Using a ternary check will give better results than a direct await
e.g. (task.IsCompleted) ? task.Result : await task;
Note: should be IsCompletedSuccessfully though the Task.Status path doesn’t inline either https://github.com/dotnet/corefx/issues/16745#issuecomment-292728779
Should the no-wait sync path be marked with aggressive inlines?
Or is the state machine going to automatically add more weight than the ternary check?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 5
- Comments: 40 (33 by maintainers)
Commits related to this issue
- Added CONSTANT_RESULTS hack for https://github.com/dotnet/corefx/issues/18481#issuecomment-294483221 — committed to protobuf-net/protobuf-net by mgravell 7 years ago
@benaadams I guess the point I’m getting at here is: you and me - we can hack around this and make our code work fine as though it wasn’t an issue; I’m thinking of “regular .NET Jo” - who is just going to use
awaitand wonder why they aren’t getting the performance they expectedMwahahahaha
Will take a while to resolve this as isn’t striaghtforward; @karelz want to assign to me? @stephentoub has :trollface:'d my ego into it
@stephentoub It will great if you write some blogs about ValueTask at https://blogs.msdn.microsoft.com/pfxteam/. Just a humble request 😀
(All that said, if there are ways we can improve the performance of
ValueTask<T>, of course we want to do that. @benaadams, I’m looking at you 😄)Why is the expectation that ValueTask will be faster than a completed task, or am I misunderstanding the concern? I fully expect that there are overheads associated with a ValueTask, e.g. it stores multiple fields that are returned, it has an extra branch, etc. This is why when I’ve been asked whether every method should just return a
ValueTask<T>instead of aTask<T>, my answer has never beenyesand ratherit depends on how often an asynchronous completion is expected, whether all T results could be cached, etc., as well as partially why there’s no non-genericValueTask(i.e. it’s no better than just returning a completed task).