ADO.NET APIs force needless Task allocations

[roji]

The ADO.NET API added async methods (e.g. DbDataReader.ReadAsync(), DbDataReader.NextResultAsync()) before ValueTask existed. Unfortunately this means that these methods return Task instances, which are heap-allocated, although in many (most?) cases the ADO.NET driver will already have the next row or resultset cached in its internal buffer (this is the case for Npgsql).

Ideally new API methods would be introduced, which would be identical in every way except that they return a ValueTask rather than a Task (how these new methods would be named is a depressing question...). Note that the above two examples may not be the only ones that could benefit from this.

[benaadams]

As they are boolean returns you can use cached true/false tasks and only go async when you need more data; something like:

private readonly static Task<bool> TrueTask = Task.FromResult(true);
private readonly static Task<bool> FalseTask = Task.FromResult(false);

public overrides Task<bool> ReadAsync(CancellationToken cancellationToken) 
{ 
    if (!NeedsMoreData)
    {
        return TryMoveNextRow() ? TrueTask : FalseTask;
    }
    else
    {
        return ReadAsyncAwaited(cancellationToken);
    }
}


private async Task<bool> ReadAsyncAwaited(CancellationToken cancellationToken) 
{ 
    await ReadMoreData(cancellationToken);

    return TryMoveNextRow();
}

[roji]

@benaadams of course, silly of me to have forgotten this. In fact, unless I'm mistaken an async method that returns Task<bool> implicitly returns a cached instance rather than instantiating. Thanks.

[benaadams]

You'll still pay the cost of the async statemachine; so may be better to split into two methods (as above) for a Task returning sync version that requires no extra data, and then have it call the async version when you need to get more data

[roji]

Yep, Npgsql has this pattern in some performance-critical paths (if data is cached return that, otherwise call an async method to load).