feat: wire performance improvements#176
Conversation
json: add Options.bytes_as_hex to encode/decode bytes fields as lowercase hex strings instead of base64 (OpenTelemetry traceId/spanId format). encode threads it via Options; decode reads a thread-local (tl_bytes_as_hex) since std.json can't carry custom options through its recursion. wire: decode fixed-size scalars via readInt, and pre-allocate capacity for packed repeated scalars/enums/submessages to cut reallocations.
| /// | ||
| /// protobuf.json.tl_bytes_as_hex = true; | ||
| /// defer protobuf.json.tl_bytes_as_hex = false; | ||
| pub threadlocal var tl_bytes_as_hex: bool = false; |
There was a problem hiding this comment.
style: while you are still at it, please do not include thread locals or globals. prefer passing arguments
There was a problem hiding this comment.
oh, wkt.any already does. I've created an issue
There was a problem hiding this comment.
yeah sorry, i want to get rid of this entirely, I do this because Otel protos have some funky stuff around hex as bytes. I'm working through in this very moment if i can get rid of threadlocal and this option as I really dislike it haha
There was a problem hiding this comment.
if you can, changing the datatype of the field from bytes to protobufs WKT bytes google.protobuf.BytesValue, the primitive will still be bytes but its serialization will be hex, for free. you would only need to hand tune the .proto and re-emit the code
There was a problem hiding this comment.
unfortunately this isn't so simple as this is the upstream proto these are generated from https://github.com/open-telemetry/opentelemetry-proto/blob/82dd303497e1bfbc86f1f8d584696195a02ea085/opentelemetry/proto/trace/v1/trace.proto#L86-L104
2 participants
No description provided.