Why is the decode side of a message pipeline usually more expensive per byte than the encode side?

## The two sides are not mirror images It is tempting to model encode and decode as the same work run backwards. They are not. **Encoding starts from a value the program already holds.** Before the first byte is written the writer knows which fields exist, what type each one is, and — in a schema-driven encoding — what tag or position each occupies. Its inner loop is short and its branches are statically known: take the next field, format it, append the bytes to one buffer, advance. The buffer grows geometrically at worst, so the write path's allocation is typically a handful of buffer doublings per message. **Decoding starts from an opaque byte range that arrived from somewhere else.** For every field, before application code sees anything, the reader must do work with no write-side counterpart: 1. **Find the boundary** — read a length prefix, walk a tag, or scan for a delimiter. A length-prefixed field's end is arithmetic; a delimited one must be scanned byte by byte, and escaped delimiters must be tracked while scanning. 2. **Decide the type** — from a tag, from the schema position, or (in a self-describing text encoding) from the shape of the bytes themselves. 3. **Validate** — the bytes came from another process. Depth, length, numeric range, character encoding and structural well-formedness all have to be checked, because everything downstream assumes they hold. 4. **Convert** — text digits to a number, escape sequences to characters, a byte range to a string. Both sides convert, but only the reader must also *reject* input that does not convert. 5. **Place the value** — allocate an object, or a slot in one, that outlives the parse call. ## Where the cost concentrates - **Allocation and collector pressure.** This usually dominates. Encoding a message with forty fields appends into one buffer; decoding it materialises up to forty values plus the container holding them, all with the message's lifetime. - **Data-dependent branching.** The writer's field order is fixed by the code; the reader's is fixed by the bytes. A dispatch per tag, in an order the branch predictor cannot learn, costs more than a predictable append. - **Memory access pattern.** The writer streams linearly into one region. The reader writes scattered objects across the heap while reading linearly from the input, so it touches roughly twice the memory. - **Error paths.** Every field needs a failure path that produces a useful message, and error construction is itself allocation. - **Character handling.** Text encodings force escape processing and UTF-8 well-formedness checks on the way in; the writer only has to emit valid output, which it can do by construction. | Step | Writer | Reader | |---|---|---| | Structure | known from the schema or the code | discovered from the bytes | | Boundaries | chosen by the writer | found by scanning or arithmetic | | Trust | output is trusted by construction | input is untrusted and must be checked | | Allocation | one growing buffer | one object per materialised value | | Branching | statically predictable | depends on the incoming data | ## Why it matters in a request path A service handling small messages under a tail-latency budget feels this twice. First, the bytes it decodes are often larger than the bytes it writes — a small query out, a full result in — so per-byte cost is applied to the larger number. Second, decode allocation lands in the hot part of the request, where a collector pause shows up directly in the percentile you are defending. Encoding a response that is then written to a socket is far easier to hide behind I/O than a decode that everything downstream waits on. ## When the gap narrows, and when it flips The direction holds broadly, but the size of the gap is not fixed: - A **schema-driven binary encoding** narrows it sharply: no field names to match, lengths present rather than scanned, types known in advance. The reader still validates and still allocates. - **Skipping** narrows it further. A reader that materialises three fields out of forty pays discovery on all of them but conversion and allocation on three. - The **encode side gets heavy** when it must compress, compute a checksum, emit a canonically ordered form, or escape large volumes of text. Any of those can make the writer the hotter half. - Runtimes differ in how they charge for the objects a decode produces — some make short-lived allocation nearly free and charge at collection time, others charge at allocation — so the *shape* of the cost differs even where the total does not. The practical conclusion is a measurement habit: benchmark the read path, under a realistic mix of messages, before assuming a symmetric cost model that the mechanism does not support.