Add streaming deserialization support for kotlinx.serialization.json

[0neel]

Follows up JakeWharton/retrofit2-kotlinx-serialization-converter#43 by introducing a new ConverterFactory specific for the Json format.

It uses Okio-based streaming API to deserialize responses.

[JakeWharton]

This incurs a lot of copies. It's probably better to depend on the Okio version of the json artifact and use the Okio-based steaming APIs.

[0neel]

Migrated to the Okio-base APIs. Could you please re-check?

[JakeWharton]

Keep this and Factory internal to this module. We don't need to share anything—the implementation isn't very big and we don't need as much indirection.

[0neel]

Ok, created module-specific Factory and converters implementations.

[0neel]

@JakeWharton is there anything else I can do to proceed with the PR?

[JakeWharton]

Sorry I haven't forgotten about this. I was waffling on what I wanted to do based on this comment: Kotlin/kotlinx.serialization#253 (comment). Specifically,

So the only option I see here is to eventually make kotlinx-io Source/Sink the default choice, and to make byte array adapters that would simply consume/write to it fully. It is the same non-ideal situation as before, but I think for real-world applications (writing to file, sending to network), IO-first implementation is preferable.

[JakeWharton]

I guess in that case we can simply deprecate this converter and add the streaming to the normal one, assuming the APIs make themselves available on the high-level "format"-suffixed types...

[0neel]

I guess in that case we can simply deprecate this converter and add the streaming to the normal one

Sounds reasonable. Until then we could use this Json-specific implementation.
Let me know if there is anything I should do before this PR can be merged.

[JakeWharton]

Yep I'll get it in here soon. Probably Monday

[janseeger]

Any news? This hasn't been merged, nor is the streaming API in the regular KotlinX Serialization Converter.

[p-dmitriy]

@JakeWharton is there plans to merge this?

[cbeyls]

The Okio-based API of Kotlinx Serialization has terrible performance (more than 2 times slower than String last time I checked) because it basically decodes one codepoint at a time; I would advise not to use it and use the java InputStream API instead for real gains.

[JakeWharton]

Streaming is always slower than buffered, yes.

The point of using the streaming APIs is that you get to amortize the cost of serialization and deserialization across the cost of the network transfer, which is orders of magnitude slower.

So instead of paying 100ms to serialize and 1000ms to transfer you effectively only pay 1000ms with streaming. Whether serialization took 100ms, 200ms, or 500ms becomes irrelevant because the limiting factor is always the network.

[cbeyls]

Why not pay even less, especially when reading the response back from the disk cache?
Since Retrofit is a Java-only project, there is no requirement to use that API.

[JakeWharton]

Okio costs less than InputStream when streaming as there are no array copies across layers.

[cbeyls]

Okio costs less than InputStream when streaming as there are no array copies across layers.

It costs less when performing comparable operations. But last time I checked, it takes much more CPU time to decode chars one by one from a BufferedSource than bulk copy a byte array then bulk decode it to a char array. Also, the Kotlinx serialization InputStream implementation recycles its byte arrays in a pool similarly to Okio, so it's quite well optimized.

See related issue in the Kotlin Serialization project: Kotlin/kotlinx.serialization#2743

[ravenfeld]

Is this becoming relevant with the new version taking a withStreaming ?

[JacobCube]

@JakeWharton do you guys plan on mergin this PR?