Generated sizes for small writes in the native serializer#

This report measures the generated-size path added for #112 . After the sizing-traversal change , scalar and nested serialize and serializeSameInstance still took 2.4 to 2.9 times Chill’s time, collections writes 2.0 to 2.5 times, and scalar and nested buildAndSerialize 1.5 to 1.6 times, while a diagnostic variant without safe sizing met the ADR-0004 tolerance in almost every cell. One plan on temporary GCE VMs compares the change with the unchanged serializer. The measurement contract is ADR-0004 ; the comparison does not establish whole-job throughput or state compatibility.

Change under test#

Before the change, every write sized the record with the iterative traversal, which reads each field through Protobuf’s reflective accessors. The changed serializer first decides whether the payload type can use the runtime’s memoized getSerializedSize(). That requires an acyclic reachable type graph whose static height, the greatest parser depth a value can reach without unknown groups, is within the recursion limit. For such a type, the serializer reads only the value’s message fields to find unknown groups and values reporting another descriptor, and its repeated strings and string-valued maps to bound their wire size from below. It then uses the generated size if that size is at most 4 KiB and the size limit, and confirms it by encoding into the existing 4 KiB scratch array; a size that wrapped around int implies at least 2 GiB of output, so that encoding fails and the traversal reports the exceeded limit. Every other value, including every payload above 4 KiB, uses the traversal as before. ADR-0001 records the conditions and the amended write-side rule; ProtobufGeneratedSizeTest compares the path’s decisions with the traversal’s.

The benchmark record is acyclic with static height 1: one nested message field without message fields of its own, and a map with int64 values. Its small workloads therefore use the generated size with one reflective read per write, and the large workload, whose payload exceeds 4 KiB, uses the traversal after that read.

Method#

The plan used the temporary GCE procedure in project flink-gcp. Each Protobuf profile ran on its own c3-standard-8 VM in asia-northeast1-b (Intel Xeon Platinum 8481C, Sapphire Rapids, 8 vCPUs, 32 GiB) from image ubuntu-2404-noble-amd64-v20261021, kernel 7.0.0-1014-gcp, with Temurin 17.0.20.1, Flink 2.3.0, and Protobuf/protoc 3.25.9 or 4.33.6. Both VMs recorded TERMINATE host maintenance and NONE as the only maintenance event, passed the load gate before every build and measurement, and reported the same machine type, CPU platform, image, kernel, and JDK. just benchmark-pair ran the ADR-0004 long-run protocol for the native and Chill Protobuf lanes, and each variant took about 70 minutes.

The baseline is the previous serializer and its tests, identical to the base under src/main; the candidate is the source commit unchanged.

Comparisons between the variants use the Chill lane as a per-block control, as in the earlier reports: the ratio of the two variants’ geometric-mean native/Chill time ratios, with a pooled two-sample Student-t interval on the five log ratios of each run (8 degrees of freedom). Below 1 favors the candidate. Allocation is the five-fork mean of JMH’s normalized allocation, in bytes per operation. These intervals are per cell, without a simultaneous claim across cells.

Results#

Writes#

Each variant cell is native time in ns/op and allocation in B/op, as five-fork means. The last three columns give the candidate’s time relative to the baseline and each variant’s native/Chill interval and ADR-0004 verdict.

Protobuf 4:

Protobuf 3:

On both profiles, the candidate takes 0.20 to 0.28 times the baseline’s time for scalar and nested serialize and serializeSameInstance, 0.36 to 0.40 for collections serialize and serializeSameInstance, and 0.46 to 0.52 for scalar, nested, and collections buildAndSerialize, and each of those intervals lies below 1. Protobuf 4 text writes take 0.41 to 0.64 times the baseline’s time. Previously encoded scalar, text, nested, and collections records now allocate 96 to 142 B/op, against 280 to 666 B/op before; buildAndSerialize keeps the allocation of building the record.

Every small write except Protobuf 3 text serializeSameInstance, which is inconclusive, now meets the native/Chill tolerance. Scalar and nested serialize and serializeSameInstance take 0.54 to 0.71 times Chill’s time, scalar and nested buildAndSerialize 0.73 to 0.82, collections writes 0.89 to 0.95, and Protobuf 4 text writes 0.66 to 0.82.

Large writes are unchanged within the intervals, all of which contain 1, and remain established at 0.27 to 0.65 times Chill’s time. They allocate 11 to 16 B/op more, which is consistent with the one reflective read before the traversal; this report does not profile it.

Protobuf 3 text writes vary more within each run than the other cells. The standard deviation of the candidate’s five log native/Chill ratios is 0.38 to 0.65 for them, against at most 0.15 for the other write cells, so their candidate-versus-baseline intervals are wide and contain 1, and serializeSameInstance is inconclusive at 0.694 (0.310, 1.558); the earlier reports recorded the same spread for these cells on Protobuf 3.

The remaining misses on both profiles are large deserialize and deserializeReuse, at 1.255 to 1.274 times Chill’s time, which #113 addresses. The large-read report measures that later change.

Reading and copying#

Reading, stream copy, and object copy run identical code in both builds.

Protobuf 4:

Protobuf 3:

Possible regressions#

One of the 50 candidate-versus-baseline intervals outside the write operations, 25 per profile, lies entirely above 1: Protobuf 3 scalar objectCopy at 1.059 (1.006, 1.115), an operation that returns its input reference in about 1 ns. No write interval lies entirely above 1. As in the earlier reports, such small intervals on unchanged paths are recorded as run-to-run drift between sequential runs and are not attributed to the change.

Limitations#

The two variants of each profile ran sequentially on one VM, over about two and a half hours, so host drift can affect native times; the Chill lane controls part of it within each block. Five blocks per run give limited information about the distribution of ratios. The plan is not compared with the earlier reports, which used other VMs, images, or kernels. The corpus has no recursive types, unknown fields, repeated strings, string-valued maps, proto2 strings, or values above 64 nested values; those use the traversal or its added checks, which the unit tests check for correctness but these measurements do not time. The corpus and warm setup do not cover first-use costs, other Flink or JDK versions, or record shapes outside the five workloads. An earlier plan, issue112-sizing-1, measured an intermediate source before the review changes; its results are not retained, and this report does not use them.

Retained evidence#

The data inventory lists the four result archives, their checksums, and how to reconstruct each measured tree.