~bigbes/tarantool

tarantool-protobuf

e258695ea1fe3b322d0ab4277bbdeed6d4eabe5e — Eugene Blikh 2 months ago a5ba47c
beads: close 0u1 (typed decoders already inline 1-byte fast path)
1 files changed, 1 insertions(+), 1 deletions(-)

M .beads/issues.jsonl
M .beads/issues.jsonl => .beads/issues.jsonl +1 -1
@@ 68,7 68,7 @@
{"_type":"issue","id":"tarantool-protobuf-b4j","title":"Docs: migration guide from built-in protobuf to pb","description":"Tarantool ships an encode-only require('protobuf') module. Document the migration path for users currently on the built-in. Cover: API surface differences (no decode in builtin; pb has encode+decode+JSON+text+gRPC+WKT), 64-bit cdata convention parity (both use cdata, no surprise), field-name conventions (both snake_case), the rename rationale (we couldn't override 'protobuf' without breaking existing users). Concrete before/after code samples.","status":"open","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:17Z","created_by":"Eugene Blikh","updated_at":"2026-05-17T15:47:17Z","labels":["docs","release"],"dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-o8n","title":"gRPC: reference network transports (http_server, netbox, http_client_unary)","description":"Ship reference transports as separate Tarantool modules (deferred from M4). Designs in docs/specs/grpc_transports.md. Three transports: (1) pb.grpc.transport.http_server — Connect-JSON over HTTP/1.1 via tarantool/http; default external transport; works with browsers and curl without an HTTP/2 proxy. (2) pb.grpc.transport.netbox — gRPC tunneled over net.box calls; first-class in-cluster path. (3) pb.grpc.transport.http_client_unary — outbound unary only via http_client. HTTP/2 termination explicitly out of scope; the transport contract is HTTP/2-shaped so the same generated code works behind Envoy. Conformance anchor: connectrpc/conformance harness (memory: connect_conformance_suite).","status":"open","priority":3,"issue_type":"feature","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:14Z","created_by":"Eugene Blikh","updated_at":"2026-05-17T15:47:14Z","labels":["grpc","transport"],"dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-2me","title":"Decide lazy-default for repeated string|bytes fields","description":"Open design question. For routing/proxy workloads that decode but don't iterate every element, repeated LEN fields could stay as unread ArrayViews until first access. Eager callers pay one extra table alloc; lazy callers skip N per-element string allocations. At 100KB Person, 26+ emails = 26+ string allocations deferrable. Decide: (a) flip default for repeated LEN, (b) gate behind a codegen mode/option, (c) leave eager as default and rely on _decode_lazy. Surface compatibility implications (callers iterate with ipairs today and expect a real array) before deciding.","status":"open","priority":3,"issue_type":"decision","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:13Z","created_by":"Eugene Blikh","updated_at":"2026-05-17T15:47:13Z","labels":["decoder","design","perf"],"dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-0u1","title":"Decoder: decode_len-style byte-then-varint symmetry in typed decoders","description":"The single-byte peek shortcut in decode_len (wire.lua:410-419) isn't replicated in decode_int32 / decode_uint32 / decode_int64 / decode_uint64 / decode_bool / decode_enum, which always call decode_varint(). Mirror the fast path in each typed decoder so the dominant 1-byte varint case skips a function call. Expected: 5-10% on scalar-heavy decodes. Memory: wire_2byte_varint_cliff (same shape, encode side, already fixed).","status":"open","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:11Z","created_by":"Eugene Blikh","updated_at":"2026-05-17T15:47:11Z","labels":["decoder","perf","wire"],"dependencies":[{"issue_id":"tarantool-protobuf-0u1","depends_on_id":"tarantool-protobuf-0an","type":"blocks","created_at":"2026-05-17T18:47:21Z","created_by":"Eugene Blikh","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-0u1","title":"Decoder: decode_len-style byte-then-varint symmetry in typed decoders","description":"The single-byte peek shortcut in decode_len (wire.lua:410-419) isn't replicated in decode_int32 / decode_uint32 / decode_int64 / decode_uint64 / decode_bool / decode_enum, which always call decode_varint(). Mirror the fast path in each typed decoder so the dominant 1-byte varint case skips a function call. Expected: 5-10% on scalar-heavy decodes. Memory: wire_2byte_varint_cliff (same shape, encode side, already fixed).","status":"closed","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:11Z","created_by":"Eugene Blikh","updated_at":"2026-05-25T04:29:45Z","closed_at":"2026-05-25T04:29:45Z","close_reason":"Premise outdated — every typed varint decoder (decode_int32/int64/uint32/uint64/sint32/sint64/bool) already inlines the 1-byte fast path at the function head, mirroring decode_len's pattern. Verified at wire.lua:513-557. Closing as already-done.","labels":["decoder","perf","wire"],"dependencies":[{"issue_id":"tarantool-protobuf-0u1","depends_on_id":"tarantool-protobuf-0an","type":"blocks","created_at":"2026-05-17T18:47:21Z","created_by":"Eugene Blikh","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-a7l","title":"Encoder: static type-elision on scalars in mode=full","description":"wire.to_uint64(v) does a type(v) dispatch in three branches (number/cdata/boolean); in mode=full codegen the field's static type is known. Emit UINT64(v) / INT64(v) directly at the call site and let LuaJIT type-guard the trace. Expected: 10-15% on scalar-heavy messages.","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-17T15:47:07Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T21:02:23Z","started_at":"2026-05-24T20:11:25Z","closed_at":"2026-05-24T21:02:23Z","close_reason":"Codegen emits typed fast variants for sint64/fixed64/sfixed64 — wire.encode_sint64_i(INT64(v)), wire.encode_fixed64_u(UINT64(v)), wire.encode_sfixed64_u(UINT64(v)) — skipping the to_int64/to_uint64 runtime type dispatch at every call site where the field type is statically known. Wire-level: added encode_sint64_i / encode_fixed64_u / encode_sfixed64_u alongside the existing encoders; encode_fixed64 is now a thin wrapper over encode_fixed64_u. INT64/UINT64 added as file-header upvalues alongside ffi.\n\nCodegen applied at: singular non-string scalar, singular required scalar, repeated non-packed per-element, extension singular, extension repeated per-element, packed scalar slow path, proto2 extension repeated. int32/int64/uint32/uint64 unchanged since they alias to encode_varint which doesn't call to_uint64 except on the slow-slow path.\n\nMeasured on c_int64.Wide encode (full mode, no PB_ENABLE_C, 4-run median):\n  lua-num inputs   2769 -\u003e 2520 ns/op   (+9.9% throughput)\n  cdata inputs    12993 -\u003e 12935 ns/op  (unchanged; to_int64 already takes the cdata fast path there)\n\nJust below the issue's 10-15% claim but real and measurable, and exactly the case where it matters (Lua-number-input is the common case for user code on sint64/fixed64 fields). Suites: test 766/766, test-c 1057/1057.","labels":["codegen","encoder","perf"],"dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-cma","title":"Encoder: inline zigzag_encode32 into encode_sint32 (one function call vs two)","description":"encode_sint32(v) = encode_varint(zigzag_encode32(v)) — two function calls. Inline as:\n\n  local function encode_sint32(v)\n      local n = bit.bxor(bit.lshift(v, 1), bit.arshift(v, 31))\n      -- existing 1-byte fast path\n      if n \u003e= 0 and n \u003c 0x80 then return string.char(n) end\n      return encode_varint_slow(n)\n  end\n\nSame for encode_sint64 (with the int64 zigzag formula).\n\nTiny win per sint encode — only matters for sint-heavy payloads. Filed for completeness; h8v makes this moot for mode=full (FFI direct writes inline the whole thing anyway). Real applicability: runtime mode encoders.","notes":"If h8v lands first, this becomes runtime-mode-only and may not be worth the duplication. Defer the call until h8v ships.","status":"open","priority":4,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:15:08Z","created_by":"Eugene Blikh","updated_at":"2026-05-18T17:15:08Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"tarantool-protobuf-yvc","title":"Feature: gRPC server reflection service","description":"PLAN.md section 8 lists gRPC server reflection as a non-goal until after M5. M5 is complete, so keep this as deferred future work. Implement standard reflection once real transport/server use cases require it.","status":"open","priority":4,"issue_type":"feature","owner":"bigbes@gmail.com","created_at":"2026-05-17T16:29:18Z","created_by":"Eugene Blikh","updated_at":"2026-05-17T16:29:18Z","dependency_count":0,"dependent_count":0,"comment_count":0}