Based on the the description of ValueTask<TResult> and the discussion at https://github.com/dotnet/corefx/issues/4708 it seems that GetFieldValueAsync<T>() (on DbDataReader and derived types) could use it to enable more efficient fine-grained async code.
Note that we haven't performed any measurements to try to understand the impact of this change, and that the higher level components we work on such as EF6 and EF Core currently would not take advantage of it, but we are creating this issue to have a chance to evaluate this improvement for other code that uses this ADO.NET API directly.
Also note that fine-grained async APIs that return Task<bool> (such as ReadAsync() and IsDBNullAsync()) may return cached Task<bool> instances to gain efficiency instead of adopting ValueTask<TResult>.
From my perspective, there are a couple of open issues if we decided to do this:
- Naming of the new method: since there can't be yet another overload that only differs on the return type, and the "standard" name with just the
Async suffix is taken.
- Compatibility for providers: It seems desirable to offer a default implementation of the Task-based method that calls
AsTask() on the ValueTask<TResult> instance returned by the new API, so that new providers don't need to implement the old Task<TResult> version of the API but instead only implement the more efficient ValueTask<TResult> version. It also seems good not to force existing providers to switch.
I am currently thinking that adding an optional interface with the new API could be a solution, but there are other disadvantages in that approach.
cc @stephentoub @YoungGah @saurabh500
Based on the the description of
ValueTask<TResult>and the discussion at https://github.com/dotnet/corefx/issues/4708 it seems thatGetFieldValueAsync<T>()(onDbDataReaderand derived types) could use it to enable more efficient fine-grained async code.Note that we haven't performed any measurements to try to understand the impact of this change, and that the higher level components we work on such as EF6 and EF Core currently would not take advantage of it, but we are creating this issue to have a chance to evaluate this improvement for other code that uses this ADO.NET API directly.
Also note that fine-grained async APIs that return
Task<bool>(such asReadAsync()andIsDBNullAsync()) may return cachedTask<bool>instances to gain efficiency instead of adoptingValueTask<TResult>.From my perspective, there are a couple of open issues if we decided to do this:
Asyncsuffix is taken.AsTask()on theValueTask<TResult>instance returned by the new API, so that new providers don't need to implement the oldTask<TResult>version of the API but instead only implement the more efficientValueTask<TResult>version. It also seems good not to force existing providers to switch.I am currently thinking that adding an optional interface with the new API could be a solution, but there are other disadvantages in that approach.
cc @stephentoub @YoungGah @saurabh500