DeserializeAsync

[benaadams]

You know those async reader methods want a user friendly entry point 😉

[JamesNK]

They do: JToken.LoadAsync

I'm not going to think about async serialization this release.

[JonHanna]

I'll be submitting a PR for this soon, for when you do decide to think about it 😄

@benaadams Do you have any thoughts on #1161? I'm personally okay with the way things are, but thought it better to consider a way it could have been better than just plow on through.

[benaadams]

Was thinking specifically of JsonSerializer.DeserializeAsync(... methods

[JonHanna]

Underway.

[JamesNK]

@benaadams What is the recommendation on exposing a valuetype Task on a public API? The serializer will call many Task<T> methods on JsonReader/JsonWriter which won't be cached. Async serialization will probably involve a lot of Task allocations.

[benaadams]

As will be mostly sync with occasional async; the fastest way is to split the two for when is data and when isn't data; something like

public ValueTask<T> ReadThingAsync()
{
    T obj;
    return TryParse(out obj) ? 
        new ValueTask(obj) : 
        new ValueTask(ReadThingAsyncAwaited());
}

private async Task<T> ReadThingAsyncAwaited()
{
    T obj;
    do
    {
        await ReadMoreData();
    } while(!TryParse(out obj));
    
    return obj;
}

[benaadams]

If you want to go C#7 then you can combine the two, though is slightly slower (middle box in examples https://github.com/ljw1004/roslyn/blob/features/async-return/docs/specs/feature%20-%20arbitrary%20async%20returns.md)

Otherwise ValueTask is NetStandard1.0 (et al) https://www.nuget.org/packages/System.Threading.Tasks.Extensions/ so think its fine to expose

[manigandham]

Is this still in progress? We deserialize directly to types from async I/O so JsonSerializer.DeserializeAsync is what we're looking for... unless there's another way to do this now?

[bruno-garcia]

@manigandham Version 10 brought async with JObject.LoadAsync and WriteToAsync.
What I haven't found a way is to use a custom JsonConverter. I guess it needs an async entrypoint anyway: JsonSerializer.SerializeAsync so I guess this is the right issue to track.

Are there any plans for this?

[eatdrinksleepcode]

I also have encountered the need for this (async deserialization using JsonSerializer when reading from a large file). Is there any update on the status?

I am happy to help contribute, but it seems like some work has already been ongoing (@JonHanna mentioned a PR in early 2017), and I would rather not start from scratch.

[manigandham]

FYI: after investigating this further, it seems deserialization to a type needs the entire json payload buffered anyway to be able to properly construct the object, so DeserializeAsync<T>(Stream) wouldn't really be much more than a convenience wrapper around a byte[] buffer.

We originally used a MemoryStream but .NET Core 2.1 has ArrayPool<byte>.Shared.Rent(...) + Span<byte> for better performance.

[eatdrinksleepcode]

@manigandham Is the need to buffer the entire payload a requirement of the algorithm, or a detail of the current implementation? I'm not an expert™, but it's not obvious to me why the entire payload would need to be available in order to parse JSON into a statically typed model.

[manigandham]

@eatdrinksleepcode You're right, I missed the code here. It does support reading from a stream incrementally and all the necessary methods are in the JsonReader.Async.cs class. The missing part is an async version of Deserialize<T>() that uses these async reader methods.

It seems to cascade through internal JsonSerializerInternalReader.cs and JsonReader.cs classes but I'm not sure of the entire scope. Buffering streams manually works well for us so far.

[michael-hawker]

@bruno-garcia how did you work around it? Is JsonConverter async related to this issue or should it be a separate issue?

[bruno-garcia]

@michael-hawker I've been using sync methods so far. Still unaware of another way.

The ASP.NET team is working on a new JSON lib to use on ASP.NET Core.

Considering the announcement's main driver of a new lib is performance, from the scalability point of view an async deserializer (assuming possible) is could also be considered.

James works there so perhaps he's be able to provide some more info on their plans?! :)