jonnify·bcs /bcs/ideas/branding-beats-its-own-integer/the-two-renderings

B1.6 · dive — the two renderings

Eleven divisions, fixed positions.

A decimal rendering of a 60-something-bit snowflake performs about 19 divmods by 10 into a variable-width buffer whose length is only known at the end. The branded rendering performs exactly 11 divmods by 62 into fixed positions 3 through 13 of a 14-byte buffer, then copies 3 namespace bytes into positions 0 through 2. Fewer divisions, no width computation, no length to return.

Source: content/bcs1.a1.md · the two renderings, derived. The structure comes first; the five clocks of the next dive test it.

The two buffers. Select a rendering to read its operation accounting — a lookup over the derivation, no clock involved.
brd14 ns copy → positions 0–2 11 divmods by 62 → positions 3–13, fixed u64dec ~19 divmods by 10 → a width known only at the end
readout · Select a rendering. Static reading: the branded form fills 14 fixed cells — 3 namespace bytes, 11 base62 payload digits; the decimal form fills about 19 cells whose total width the code learns only after the last division.
§1

The derivation

content/bcs1.a1.md · the two renderings, derived

The structure predicts a win for the brand wherever both forms run as compiled userland code — eleven divisions into positions fixed before the first one runs, against nineteen into a width the code must then account for. It leaves a question mark wherever one side gets engine-level help: V8’s decimal conversion is engine C++, while a userland BigInt base62 pays interpreter-level costs per divmod. And it predicts the storage column unconditionally: five fewer bytes per key pushed the embedded object down one allocator size class in Chapter 1.3’s measurement, 65 against 73 on Valkey 8.1’s single-allocation entries.

Nothing in this dive runs a clock. The derivation fixes what the benchmarks are allowed to mean before they exist — where the compiled rows of the next dive confirm it, that is the structure cashing; where the Node row contradicts it, that is the engine-help question mark resolving against the userland side.

§2

The storage column, unconditional

inherited from Chapter 1.3 · bench/valkey-id
content/echo_data/bench/valkey-id/valkey_id_bench.out · brd14 / u64decfrozen
fmt     keylen  redis7  valkey81  saved
brd14   14      88      65        23
u64dec  19      104     73        31

The rows are Chapter 1.3’s record, inherited verbatim — value an 8-byte embstr, one million keys per run. The branded 14-byte form costs 65 bytes per key on Valkey 8.1’s table; its own 19-digit decimal rendering costs 73 — 8 bytes more. Whatever the clocks return, this column is settled: the same integer, dressed in its own decimal digits, is the more expensive tenant.

§3

Three accountings

content/bcs1.a1.md · the derivation, itemized
The operations ledger. Select an accounting; the readout compares the branded answer with the decimal answer.
readout · Select an accounting. Static comparison: 11 divmods by 62 against about 19 by 10; a 14-byte width fixed before the first division against a width known only at the end; no length to return against a length computed last and carried with the text.

The ledger is the whole argument in three rows. The denser alphabet retires eight divisions before any clock runs; the fixed layout deletes the width computation; the constant length deletes the return value. What the ledger cannot settle — the engine-help question mark — is the next dive’s subject, where the five committed clocks resolve it runtime by runtime.

§4

References

sources · related

Sources

Related