~bigbes/tarantool-protobuf: wire: document why encode_varint's fast path stays 1-byte only

add2f224a35dd8b9ce38995cfe76f7715e78d3cd — Eugene Blikh 3 months ago a33dbec

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.

patch browse .tar.gz .zip

1 files changed, 5 insertions(+), 0 deletions(-)

M runtime/pb/wire.lua

M runtime/pb/wire.lua => runtime/pb/wire.lua +5 -0

@@ 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)