For the last few months, I’ve been running little experiments comparing programming languages — mainly JavaScript, Go, and C++. It’s my way of mixing curiosity with coffee on a quiet Sunday morning.
This time, I wanted to explore a simple but nagging question: how slow is JSON parsing, really? JSON is everywhere in APIs, yet I’ve often heard it’s not an efficient format compared to binary alternatives. So, I decided to measure it for myself.
The Dataset
I pulled a dataset from nyc.gov with over 3.4 million yellow taxi trips.
- Parquet file size: fairly small
- Converted JSONL file size: ~1.5 GB
The task: read the file and parse each line as JSON. Simple enough.
JavaScript: The Baseline
First up, JavaScript with JSON.parse.
- Time taken:
3,620 ms(~3.6 seconds)
Not blazing fast, but it gave me a baseline. I even tried writing a custom JSON parser in JS, but it was nowhere close in performance. At that point, I figured maybe I needed a lower-level language.
Go: Built-in vs Sonic
Next stop: Go. I implemented the same logic using Go’s standard JSON parser.
- Time taken (built-in parser):
12,002 ms(~12 seconds)
That’s more than 3x slower than JavaScript. At first, I thought I had written something inefficient. But after a bit of research, I learned Go’s standard JSON parser is notoriously slow.
So I turned to Sonic, a high-performance JSON library for Go that leverages SIMD (similar to JavaScript’s engine optimizations).
- Time taken (Sonic):
3,493 ms(~3.5 seconds)
Basically the same as JavaScript.
C++: The Winner
Finally, I tested C++ with a JSON parsing library that also uses SIMD.
- Time taken:
1,229 ms(~1.2 seconds)
Now we’re talking! This was nearly 3x faster than JavaScript and Go with Sonic. My belief that lower-level languages could still outperform held true here.
Key Takeaways
After this little weekend experiment, here’s what I learned:
- Always measure. Assumptions about performance are often wrong until tested.
- JSON isn’t fast. It’s convenient and ubiquitous, but far from efficient.
- Time disappears quickly. I lost hours tinkering with a homemade parser that never came close to production-ready performance.
Final Thoughts
This wasn’t a scientific benchmark — more of a curiosity-driven exploration. But it reinforced something I’ve seen throughout my career: the right tool depends on context. JavaScript is good enough in many scenarios, Go offers simplicity with trade-offs, and C++ still shines when raw speed matters.
Sometimes it’s not about rewriting everything in C++ for performance — it’s about knowing where those trade-offs exist.