How a Little Grammar Saved 47% of Our CPU

Every JSON object starts with { or [. That one line from the JSON spec became a 5-line fix that cut a production server's CPU by 47%.

contents

Every valid JSON object starts with {. Every valid JSON array starts with [. That’s the whole insight. It’s written right there in the JSON grammar, in a diagram most of us scrolled past years ago.

That one line of grammar recently saved 47% of our production CPU.

img1-grammar-2.png

The setup

I work on a backend service that pulls data from hundreds of third-party APIs, thousands of times a minute. Every response gets walked recursively so we can process each value inside it.

Deep in that walk sits a tiny helper: isJSON(str). Given a string, tell me if it’s a JSON object or array. It was written the way most of us would write it: try JSON.parse, return true if it gives an object, catch the throw and return false.

Clean. Correct. It passed every review it ever faced, because logically there’s nothing wrong with it.

The crime scene

The service was slow, and the obvious answer on the table was more capacity. I pushed back. Before we scale anything, I wanted to know why it was slow. So I profiled it.

The profiler pointed at isJSON. One tiny helper was eating 47% of the entire CPU.

img3-cpu-2.png

Here’s why. It runs on every leaf value of every response. And most leaf values are names, emails, IDs, timestamps. Plain text. Almost none of it is JSON. So almost every call took the failure path: JSON.parse("hello") throws, and in V8 a throw isn’t free, roughly 31 microseconds each. Multiply that by every field of every record of every request, all day long.

We weren’t parsing JSON. We were manufacturing exceptions at industrial scale.

The grammar

A JSON object must begin with {. An array with [. So if a string’s first meaningful character is anything else, you already know the answer without parsing anything.

The fix is a guard before the parse: peek at the first non-whitespace character, return false immediately if it isn’t { or [, otherwise fall through to the real JSON.parse. Five lines. Processing time dropped to half, in production, the same day.

img2-beforeafter-2.png

The trap inside the fix

One subtle detail. To peek, you trim leading whitespace. The tempting move is to pass the trimmed string to JSON.parse too. Don’t. trimStart() strips characters that JSON.parse rejects, like BOM and non-breaking spaces, which some Microsoft-stack APIs actually send. Parse the trimmed string and you’ve silently changed behavior while “just optimizing.” So the trimmed copy is used only for the peek; the original goes to the parser.

What I learned

The lesson isn’t “exceptions are evil.” It’s that a grammar isn’t just rules for validity, it’s information. The first character of a JSON document tells you its type before you’ve read anything else. Compilers exploit this constantly; it’s why predictive parsers work with one token of lookahead.

The most expensive code in your system is rarely the clever code. It’s the innocent helper doing something reasonable, millions of times, on inputs that were never going to succeed.

Read the grammar. It’s shorter than the profiler output.

I’m Gaurang Sharma — I build backend systems and chase down the distributed-systems failures they produce. I’m open to backend / distributed-systems roles.