Serializer implementation performance check#

This local comparison measures the getter-name removal, metadata cache, and sizing refactor against commit f6a6e33d272f74da80f82e9d77718399cda9702e. The candidate is the implementation accompanying this report. It is a small implementation comparison, not a ranking against other formats or an end-to-end Flink throughput result. The maintained cross-format harness and its v0.1.0 baseline work are described in the serializer benchmark report , tracked in #30 .

Conditions#

Measurements ran on 2026-09-11 using an Apple M1 Pro with 32 GiB RAM, macOS 26.6.2, and Temurin 17.0.20+8. Both variants used Flink 2.3.0, JMH 1.37, G1 GC, a fixed 256 MiB heap, and one benchmark thread. Protobuf runtime and generated fixtures were paired at 3.25.8 and 4.33.6 in separate classpaths. Each case used two JVM forks, three 500 ms warmup iterations, five 500 ms measurement iterations, average time mode, and the JMH GC profiler. Final comparisons ran sequentially without concurrent builds or another benchmark. The table reports the JMH mean and its 99.9% confidence interval half-width; allocated bytes are rounded per operation. These short runs on a development machine cannot establish small performance differences reliably.

The temporary harness compiles the baseline or candidate production sources with the corresponding generated test fixtures and JMH annotation processor. Its timing command is equivalent to:

java -cp "$BENCHMARK_CLASSPATH" org.openjdk.jmh.Main SerializerBenchmark \
  -f 2 -wi 3 -i 5 -w 500ms -r 500ms -bm avgt -tu ns -t 1 \
  -jvmArgs '-Xms256m -Xmx256m -XX:+UseG1GC' -prof gc -rf json -rff results.json

This implementation comparison’s harness and raw JSON remain local investigation artifacts. The separate maintained benchmark provides independently runnable cross-format comparisons. No benchmark dependencies enter this library’s production artifact.

Workloads#

All serialization cases reuse a single immutable generated value and a serializer with default settings. The timed operation clears a preallocated 128 KiB DataOutputSerializer, calls serialize(value, output), and returns the resulting framed length to JMH. Setup checks that the frame length equals value.toByteArray().length + 4 before measurement. Inputs, generated accessors, memoized runtime sizes, and buffers are therefore warm; fresh-record construction and cold class initialization are not measured.

Results#

Caching validated metadata removes repeated reflective default lookup, parser validation, and descriptor normalization from warm serializer construction. That construction result does not imply a comparable per-record or whole-job speedup. In the measured candidate, ordinary serialization still traversed fields and allocated sizing metadata, but it did not perform this initialization work on each record; the sizing-allocation report measures the later traversal change.

The raw-string path replaces generated getter-name guesses with one bounded counting pass through public APIs. It can allocate more for a small raw message, while removing per-occurrence reflection/cache-key work in nested messages. The candidate counts the root once after validating the entire graph, so nested ambiguous strings do not cause one counting pass per message node. The implementation does not retain records or their size summaries between calls.

This check does not cover deserialization, copying, cold classloading, fresh-record allocation, other Flink/JDK versions, or all schema shapes. Those results must not be inferred from this table; compatibility remains covered separately by the project’s verification matrix. No timing threshold is added to shared-runner CI.