refactor: Prefer KxS's string API over the stream API

[sschuberth]

The string API is generally considered to be faster, see e.g. 1 and 2.

[sschuberth]

FYI @nnobelis, this is the opposite of what I was asking from you over here 😬

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.63%. Comparing base (efed39f) to head (502c3ed).
Report is 227 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #8902   +/-   ##
=========================================
  Coverage     67.63%   67.63%           
  Complexity     1168     1168           
=========================================
  Files           244      244           
  Lines          7781     7781           
  Branches        867      867           
=========================================
  Hits           5263     5263           
  Misses         2161     2161           
  Partials        357      357           

Flag	Coverage Δ
funTest-docker	67.39% <100.00%> (ø)
funTest-non-docker	33.90% <ø> (ø)
test	37.91% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mnonnenmacher]

I find the linked discussions not convincing, the first one closes with the question if some performance improvements in version 1.5.0 changed the situation, but this was never answered. We are now at version 1.7.1, so it's possible that more optimizations have been implemented in the meantime. Also, the benchmark was done on an Android device which could be different to the JVM we use.
And the second one does not really seem to compare parsing from a string to parsing from a stream.

As the memory usage should always be higher when first reading to a string, I would like to see an actual benchmark that compares both for the current version of kotlinx.serialization before doing the switch.

[sschuberth]

As the memory usage should always be higher when first reading to a string

True, but that probably does not matter much for the size of the data we're dealing with in the changed code places. Performance for the same reason does not improve much either, but the string API is also a bit easier to use as it requires less code.

[fviernau]

IMO it would be nice to add our own decodeFromFile<>() extension function.
This could then internally either use the string or the stream API at our preference.
In any case it would save us a couple of lines of code.

[sschuberth]

This could then internally either use the string or the stream API at our preference.

And we could even select the API dynamically on the file size. I'll look into that.

[sschuberth]

IMO it would be nice to add our own decodeFromFile<>() extension function.

As it would be a bit unclear where to put such a function (I do not want common-utils to depend on KxS in the same way they already depend on Jackson), I'm closing this for now. Maybe the discussion over at KS3 will be fruitful.