mostafa / xk6-kafka / 26884255213

79%

push

github

perf(protobuf): cache compiled FileDescriptor by schema content (#398)

* test(protobuf): add benchmarks for descriptor compile hot path

buildProtobufRuntime and ProtobufSerde.Serialize are called on every
schemaRegistry.serialize() invocation. The new benchmarks loop the call
against a fixed *Schema instance so allocs/op surfaces any repeated
compilation cost. Baseline (M3 Pro, Go 1.26.0):

    BenchmarkBuildProtobufRuntime-12     52964 ns/op    74423 B/op    605 allocs/op
    BenchmarkProtobufSerdeSerialize-12   61197 ns/op    77500 B/op    679 allocs/op

The high alloc count per call is what makes the serialize hot path OOM
runners that hold a *Schema across thousands of iterations; the next
commit caches the compiled runtime to bring this down.

* test(protobuf): prove JS path allocates fresh *Schema per call

decodeArgument (validation.go) marshals the JS-side argument to JSON and
unmarshals into the Go-side target struct on every call, fabricating a
brand-new *Schema each time even when the JS-side object is the identical
reference. The new unit test calls decodeArgument twice with the same
sobek.Value and asserts the resulting Schema pointers differ; the new
benchmark mirrors the JS-facing serialize() path by running decodeArgument
inside the loop, surfacing the cost of the round-trip and proving that any
descriptor cache for the JS hot path must key on schema content rather
than *Schema identity.

* perf(protobuf): cache compiled FileDescriptor by schema content

protocompile.Compile is invoked from parseProtobufFileDescriptor on every
Serialize/Deserialize call, allocating ~75 KB / ~679 heap objects per call
against a small schema with one dependency. A k6 load-test runner calling
schemaRegistry.serialize() in a hot loop OOM-killed at 4 GiB within 35s
at 100 msg/s.

The JS-facing handlers route the argument through decodeArgument, which
json.Marshal/Unmarshal-round-trips it and allocates a fresh *Schema every
call (proven by TestDecodeArgume... (continued)

26 of 26 new or added lines in 1 file covered. (100.0%)

3782 of 4793 relevant lines covered (78.91%)

33.66 hits per line