supabase / supabase-flutter / 40330369462

94%

push

github

perf(yet_another_json_isolate,postgrest,functions)!: encode request bodies to UTF-8 bytes on the calling isolate in slices (#2057)

Large inserts were slower in v3 than in v2, and moving their encoding to
an isolate did not take the work off the calling isolate. `Isolate.run`
copies the whole payload on the calling isolate before encoding it, and
the copy grows with the payload. On top of that, every client encoded
the body twice: to a JSON string, then to UTF-8 when the string was
assigned to `request.body`.

This encodes request bodies straight to UTF-8 bytes on the calling
isolate. A top-level list, such as the rows of a bulk insert, is encoded
in batches that yield to the event loop every 2 ms, so a frame is never
blocked for long however large the payload is. Decoding is unchanged and
still runs on short-lived isolates.

## Changes

- `AsyncJsonCodec` gains `encodeBytes`, the counterpart of
`decodeBytes`. Both encode methods may now read the value until their
future completes.
- `YAJsonIsolate` encodes on the calling isolate, slicing a top-level
list. The isolate encode path and the pass that estimated the payload
size beforehand are removed. Web uses the same encoder, so it no longer
blocks for the whole encode either.
- `PostgrestBuilder` sends the body with `request.bodyBytes`. The
content type stays `application/json`.
- `FunctionsClient` sends a body with a JSON content type as bytes. Any
other content type still goes through the string path, so a
caller-provided charset such as `iso-8859-1` keeps working.

## Breaking change

An `AsyncJsonCodec` implementation has to add `encodeBytes`.
`AsyncJsonCodec` is new in v3, so this only affects the v3 pre-releases.

## Measurements

From a benchmark of the client itself, using a canned HTTP transport,
compiled ahead of time on macOS arm64. "Frame blocked" is the median of
the longest time per request in which the calling isolate could not run
a timer.

| Insert | v2 | v3 before | v3 after |
| --- |... (continued)

53 of 55 new or added lines in 4 files covered. (96.36%)

12079 of 12841 relevant lines covered (94.07%)

6.21 hits per line