From add2f224a35dd8b9ce38995cfe76f7715e78d3cd Mon Sep 17 00:00:00 2001 From: Eugene Blikh Date: Fri, 15 May 2026 14:16:50 +0300 Subject: [PATCH] wire: document why encode_varint's fast path stays 1-byte only Adds a comment explaining the failed experiment with 2/3/4-byte fast paths: extending the function past the LuaJIT inline budget makes parent traces stop inlining it, costing ~30% on 1-byte-dominant workloads (and the bench payload is 1-byte-dominant since most proto field tags, enum ordinals, and short-string length prefixes fit in 7 bits). Future maintainers should resist the temptation. No code change beyond the comment. --- runtime/pb/wire.lua | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/runtime/pb/wire.lua b/runtime/pb/wire.lua index 8e21add2974bcf573c114e2a3e54985a02ab8890..0b6046da420859ef5c600248b20adde1a77ef285 100644 --- a/runtime/pb/wire.lua +++ b/runtime/pb/wire.lua @@ -50,6 +50,11 @@ M.to_int64 = to_int64 -- string.char(n) call with no cdata allocation, no `out` table, no -- table.concat. Covers most length prefixes for short strings, many -- enum ordinals, and most small int values in typical RPC payloads. +-- +-- We deliberately do NOT extend the fast path to 2-4 byte values: +-- growing the function past the LuaJIT inline budget makes parent +-- traces stop inlining it, which costs more (~30% bench regression +-- on 1-byte-dominant workloads) than the rare multi-byte case gains. local function encode_varint(n) if type(n) == 'number' and n >= 0 and n < 0x80 then return string.char(n)