Why does parsing a text-encoded message usually cost more processor time than reading a length-prefixed binary one?
answer
- discover the boundary or be told it
- a branch per character
- digits are not a number
- skip by stored length
- unwanted fields are not free in text
basics
~20 sText parsing works character by character: it must find where each value ends and then convert digit characters into a number. A length-prefixed binary reader is told each field's width up front, so it reads or skips without inspecting content.
solid answer
~50 sThe costs differ because the two readers are asked different questions. A text parser cannot know where a value ends until it has looked at the characters, so it takes a branch per character to find delimiters, handles escapes inside strings, and then converts sequences of digit characters into numeric values — decimal-to-binary conversion is real arithmetic, not a copy. A **length-prefixed** binary reader is told the width of a fixed-width field, or reads a length and then knows exactly how many bytes follow; it can copy the field or advance past a field it does not want without examining a single byte of content. That skip is the underrated part: an uninterested text parser still has to scan the region it wants to ignore, because only the characters reveal where it ends. The gap is usually a small multiple rather than an order of magnitude, and it depends heavily on the quality of the parser.
code
pseudocode · 15 lines// text: the end of the value is hidden in the characters
i = start
while i < end and is_number_character(byte_at(i)):
i = i + 1
value = convert_digits_to_number(bytes, start, i) // arithmetic per digit
next = i
// length-prefixed binary: the layout states the extent up front
width = 8 // from the field definition
value = read_fixed_width_integer(bytes, start, width)
next = start + width
// and skipping a field you do not want
length = read_length(bytes, position)
position = position + size_of_length + length // content never examinedgo deeper
Remember the core asymmetry: a text reader has to look at characters to find where a value ends, while a binary reader is told the width or length before it reads anything.
Explain the per-value steps — boundary scan, escape handling, digit-to-number conversion, name matching — and contrast them with a sized read and a length-based skip.
Tie it to a real profile: say whether the hop is bound by the link or the processor, and show that the fields a consumer ignores are free in one layout and not in the other.
Judge whether decode cost is worth a platform-wide encoding change at all, given that a better parser, fewer fields per message, or a narrower consumer contract may buy the same headroom for less disruption.
## What a text parser has to do per value A text grammar hides the boundaries of a value inside the characters themselves, so the parser must discover them: 1. **Find where the value ends.** There is no width to consult, so the reader advances through characters testing each one against the grammar's delimiters. 2. **Handle escaping inside strings.** A delimiter character can appear inside a string in escaped form, so the scan is not a plain search for the next delimiter; it is a small state machine. 3. **Convert numbers.** Digit characters are not a number. Turning them into one is arithmetic per digit, and producing a binary floating-point value from a decimal fraction correctly is harder still. 4. **Validate the character encoding.** Characters may be multi-byte, and a correct reader checks the byte sequences rather than assuming them. 5. **Match field names.** When names are spelled out in the message, each one is compared against something the reader knows before the value can be placed. Every one of those steps is driven by data, which means a branch that depends on the byte just read. ## What a length-prefixed binary reader does instead - A **fixed-width field** has a width fixed by the definition, so the reader advances by a constant and interprets the bytes directly. - A **length-prefixed field** stores its byte count first, so the reader learns the extent of the value before touching it. - A **field it does not want** is skipped by adding the stored length to the position — content never examined. - A **numeric tag** replaces a spelled-out name, so identifying the field is an integer comparison rather than a character comparison. ## Where the time actually goes | Per-value work | Text encoding | Length-prefixed binary encoding | | --- | --- | --- | | Locate the end of the value | Scan characters, one branch each | Read a width or a stored length | | Interpret a number | Convert digits, arithmetic per digit | Interpret the bytes as they stand | | Identify a field | Compare spelled-out names | Compare a numeric tag | | Ignore an unwanted field | Still scan it to find its end | Advance by the stored length | The last row is the one candidates miss. A reader that cares about two fields out of thirty still walks every character of the other twenty-eight in a text grammar, whereas the binary reader jumps over them. ## What this does and does not predict - **Compression does not help here.** A compressor shrinks what travels on the link. The receiver decompresses and then performs exactly the same character scan it would have performed anyway, plus the decompression work. - **The gap is a multiple, not a law.** A carefully engineered text parser narrows it considerably, and a naive binary reader can squander the advantage. Quoting a fixed ratio is a mistake; naming the mechanism is the answer. - **It only matters when the hop is bound by the processor.** On a link-bound hop the decode difference is invisible and the byte difference is what counts. - **The values themselves are identical.** Decode cost is a property of how the bytes are laid out, not of what they mean. ## Why the skip matters more than it looks Messages grow over time. A consumer typically reads a handful of fields out of a message that carries many, because other consumers need the rest. In a compact layout with lengths, the cost of the fields you ignore approaches nothing. In a character grammar it is proportional to their size, which means a consumer pays for other teams' fields forever. That asymmetry, rather than raw throughput on a synthetic benchmark, is what usually shows up first in a real pipeline. ## Answering it well - Lead with the mechanism: discovering a boundary against being told one. - Name number conversion explicitly — it is the part people forget, and it is genuine arithmetic. - Mention the skip: unwanted fields are free in one form and not in the other. - State the limits of your own claim: it is a multiple, it depends on the parser, and it only matters when decode cost is on the critical path.
- A consumer needs three fields out of a message that carries forty. How does that change the comparison?It widens the gap sharply. In a length-prefixed layout the thirty-seven unwanted fields are skipped by adding their stored lengths, so their cost is close to zero. In a character grammar the parser must scan every one of them to discover where it ends before it can reach the next field, so the consumer pays in proportion to fields it never uses.
- Does compressing the text payload reduce the receiver's decode cost?No, it increases it. The link carries fewer bytes, but the receiver must decompress and then run the identical character scan over the identical characters. Compression addresses payload size; it leaves the parsing work untouched and adds work of its own. Treating the two costs as one is the usual error here.
saying these in an interview costs you the question
- Says text parsing is slower only because the payload is larger
- Believes a binary reader must still scan every byte to find where fields end
- Claims compressing the text lowers the receiver's decode cost
- Assumes turning digit characters into a number is effectively free
- Quotes a fixed speed ratio as if it held for every parser and message