Hello community! We are excited to announce the major update of our JSON parser without code generation and allocations -- silentjson v2.0.0.

First of all, a huge thank you to everyone who supported the project and provided feedback. We wouldn't have come this far without your involvement.

What is new in v2.0.0?

In this release, we focused on ultimate efficiency and specific high-load use cases:

• Scalar parsing optimization (non-AVX2). We have significantly improved the scalar fallback. Now, even on architectures without modern vector instruction support or where they are disabled, the parser shows excellent results.
• hft-ipc. Those who know, know.

The icing on the cake: hitting the physical limits

The main news of the release -- the speed has accelerated so much that we simply stopped being able to catch up. We have practically eliminated software overhead and are now simply hitting the raw hardware and memory bandwidth.

It is cool, yes. But we have to be honest: an extremely heavy load has an impact on us as well. To be fair, in a stress scenario simulation under heavy load, the parsing speed dropped by 60%. But even with this drop, silentjson continues to outperform all competitors by an insurmountable margin. The safety margin turned out to be colossal.

Here is a small teaser with tests on AMD Ryzen 9 7950X3D (parsing 100,000 objects):

(Details later or on GitHub)

Do not take our word for it

Do not forget about our contribution and go check if we have deceived you. Just in case.

Update to the latest version:

go get github.com/GenshIv/silentjson@v2.0.0

Post your benchmarks in the comments to this article. Who can do more!

Project Repository: github.com/GenshIv/silentjson

Optimization is always good, of course. But let's be honest: the business needs a product. Here and now. The business rarely thinks about what comes "later". That's why they hire a team of developers and demand features. They need it written faster, shipped faster, and sold faster.

But you don't have to sell just products or features. You can sell solutions.

Imagine a classic scenario: the business has grown, and traffic has skyrocketed (or we started selling 5 times more cupcakes). I had a real case in my practice. They come to me and say: "We urgently need to buy 3 more servers, we can't handle the load". And I look at the metrics and reply: "What for? Our current servers are only at 20% capacity".

Has this ever happened to you? Usually, it's the exact opposite. Developers themselves are begging: "Give us more hardware, our microservices are suffocating".

Now imagine a different dialogue: Business: -- Why did we even buy such an expensive server if it's sitting practically idle right now? You: -- Because the conditions and architecture were different back then. Now, we've made the code run efficiently.

Do you know what the main problem is? The business buys "features", even though it actually wants to buy a solution. But very few people actually sell those solutions. Most often, developers just sell "delayed headaches" with the condition of buying new hardware and endlessly scaling horizontally.

It's hard to blame the programmers here. We all live in a certain engineering culture where abstractions take center stage, and understanding how the hardware actually works is considered "low-level" and unnecessary. Let's look at how we got here through three famous quotes.

>"Software is getting slower more rapidly than hardware becomes faster." -- Niklaus Wirth, creator of Pascal (Wirth's Law, 1995).

In the race for development speed, we started hiding the hardware behind thick layers of frameworks, virtual machines, and Garbage Collectors. We are "burning" all the massive computing power that modern multi-core processors give us just to maintain these abstractions. Hardware gets more powerful every year, but programs run slower and slower for the end user.

>"We broke monoliths into microservices to solve management problems, not performance problems." -- Kelsey Hightower, one of the main evangelists of Kubernetes.

Many young developers believe that microservices are synonymous with HighLoad and speed. In reality, we took a lightning-fast local memory call (which took nanoseconds) and replaced it with a slow network request with endless JSON serialization (which takes milliseconds). The industry voluntarily traded pure CPU speed for insane network latency.

And finally, we got way too carried away with trendy design patterns:

>"I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind." -- Alan Kay, one of the creators of Smalltalk (OOPSLA '97).

A bit later, he added:

>"I’m sorry that I long ago coined the term “objects” for this topic... The big idea is messaging."

We somehow unnoticeably got carried away with beautiful objects, abstract factories, and layers, completely forgetting how the system actually communicates internally and how this code will eventually be executed in silicon.

But there is another way. We can "sell" servers to the business without physically selling them. Even servers that haven't been bought yet!

The point is, if you deeply study your domain, you can strip away all the architectural fluff. You can implement your idea so that it eats microscopic CPU ticks, rather than entire server racks. Essentially accelerating the system and reducing resource consumption not just by a factor of ten, but by hundreds of times.

Engineering is when your code works in synergy with the processor, not fights against it.

Join our community at r/HiLoad. Let's find elegant solutions, not just "ship features".

And now, a question for you: How often have you managed to convince the business when they asked to "just buy more hardware", instead of giving you time to find and optimize the bottleneck in the architecture? Share your stories!

Hey r/HiLoad,

I wanted to share a war story from a past project. We were dealing with a classic nightmare: receiving millions of products from suppliers and having to classify them instantly as their price lists came in.

Because it was the trendy thing to do, we initially threw a neural network at the problem. In production, it was actually pretty snappy. But the training phase? An absolute dumpster fire. The human factor completely ruined it because the team responsible for managing the catalog and keywords was frankly just phoning it in.

They kept feeding absolute garbage into the training set. Naturally, the model choked on this chaos and started hallucinating wildly. My personal favorite was when it confidently classified a massive batch of toilet paper into the "Baby Car Seats" category. You can imagine the collective groan from the dev team when we had to stay up half the night manually unscrewing thousands of misclassified items after a "successful" release.

To make it all worse, retraining this beast took up to two weeks. And the punchline? Because the catalog team never stopped making mistakes, we had to kick off this miserable two-week process almost every single month. Two weeks of training, maybe two weeks of peace, then someone uploads garbage again, paper towels suddenly belong in Auto Parts, and we're back in hell.

We desperately needed a solution that was dead-simple, rock-solid, easy to debug, and -- most importantly -- didn't need two weeks to learn what a car seat is. The fix turned out to be surprisingly elegant: we ripped out the ML magic entirely and replaced it with pure math.

From Words to Numbers: The Magic of Overflow

The core idea was to turn any product description into a tiny, numerical "fingerprint."

The pipeline was stupidly simple:

1. Take the raw product name.
2. Strip out all the garbage (stop words, prepositions).
3. Run it through a stemmer to just get the root words.
4. Hash each meaningful root into an int64.

Here’s the fun part. We didn't store an array of hashes. We just added them all together using standard binary addition. The trick here is that when you add large numbers in int64, you get a natural overflow, which just drops the most significant bits. In Go (and C/C++), this is completely legal, costs zero CPU cycles, and happens instantly.

The code looks almost too simple:

import "hash/fnv"

// Hash a single cleaned root word
func hashWord(word string) int64 {
	h := fnv.New64a()
	h.Write([]byte(word))
	return int64(h.Sum64())
}

// Get the numerical fingerprint for the whole product name
func getProductFingerprint(tokens []string) (hashSum int64, wordCount int) {
	for _, token := range tokens {
		// Stop-word filtering and stemming happens around here
		if isStopWord(token) {
			continue
		}
		
		wordHash := hashWord(token)
		
		// Standard binary addition. 
		// The int64 overflows naturally—no panics, no worries.
		hashSum += wordHash 
		wordCount++
	}

	return hashSum, wordCount
}

Just like that, we packed the "meaning" of an entire product name into exactly one int64 -- regardless of whether it had three words or ten. We'd also generate a few of these fingerprints per product to cover permutations and weird supplier spellings.

The Index and Foolproofing

That int64 became our key. For lookups, we just threw it into a standard in-memory Map. The value was a tiny struct:

1. ID of the target category or product model.
2. Word Count -- the exact number of tokens that built this hash (that wordCount variable from the code).

Why keep the word count? That was our bulletproof vest against collisions and our secret weapon for smart ranking.

When a new item came in from a price list, we'd run its name through the pipeline and hit the Map. If the int64 matched, we absolutely had to check if the word counts matched too. This took the chance of a false collision (two different sets of words accidentally summing to the same hash) down to mathematical zero.

During a lookup, we'd generate fingerprints for various combinations of words in the name. If we got multiple hits, the category that matched the highest number of words won. Longer phrase = more accurate match.

Trust, but Verify (The Dev-Tool)

Given our PTSD from the catalog team (never forget the toilet paper car seats), we refused to do any more blind debugging. If an item went to the wrong category, we wanted receipts.

So, we built an internal Dev-Tool. You paste a product name in, and it spits out the exact thought process: how it was tokenized, the stemmed roots, the int64 hashes, and crucially -- which exact words matched the database and which were ignored.

You can't argue with transparent math. Whenever someone complained about a misclassification, we could find the culprit (usually a horribly written keyword rule) in two clicks, rather than spending hours trying to decipher neural network logs.

Performance

The numbers were great. Even with 5 million unique products (which balloons to tens of millions of records when you add the hash variations), the whole index (int64 Key + Category ID + Word Count) barely took up a couple hundred megabytes.

The entire thing lived comfortably in RAM. Classifying a single item meant a couple of fast hashes and an O(1) map lookup. We were chewing through incoming price lists at the speed of the network interface while the CPU basically sat there twiddling its thumbs.

Scaling it out

Since it was just a Map, it scaled horizontally like a dream. We just distributed the heavy price list streams across worker goroutines. No DB transactions, no table locks, no massive SQL queries -- just pure arithmetic and memory reads.

We also reused this for validation. If a supplier sent a product and its fingerprint matched a model we already knew, the system instantly recognized it as a duplicate. We just attached the new price to the existing item and kept the catalog completely clean.

TL;DR: ML isn't always the answer. Sometimes, adding a bunch of hashes together and letting the integer naturally overflow gives you an instantly searchable, O(1) in-memory index that takes up almost no RAM and doesn't take two weeks to train.

Curious to hear from you guys -- how would you handle cache invalidation for an in-memory setup like this if the business decides to change the stop-word dictionary or stemming rules on the fly? Would love to hear your thoughts.

If you’ve ever spent days hunting down a memory leak, fought the Garbage Collector in production, or rewritten a perfectly readable function into an ugly, unsafe assembly kernel just to squeeze out an extra 500 MB/s of throughput — welcome home.

I created r/HiLoad because I felt something was missing in the standard programming subreddits. Too often, deep technical posts about performance optimization or niche architectural choices are met with "just use the standard library," or worse, removed by moderators for "self-promotion."

Here, the rules are simple and built for engineers:

1. Performance over purity We respect beautiful code, but we respect production metrics more.

2. Bring the receipts (Data & Benchmarks) We love flame graphs, allocation metrics, and throughput numbers. We love data.

3. Show and Tell (Yes, you can share your projects!) If you built a crazy fast tool, library, or pipeline — share it! Self-promotion is absolutely allowed and encouraged here, as long as you provide technical context. Tell us the problem, how you solved it, the tradeoffs you made, and what didn't work.

What to post:

• Deep dives into backend architecture at scale.
• Optimizing CPU, Memory, or I/O.
• Database scaling and query tuning.
• "War stories" from production outages and how you fixed them.
• Benchmarks and performance comparisons of languages/frameworks.

Make yourself at home. Drop a comment, share what you're currently working on (or struggling with), and let's build a community that actually cares about how things run under the hood.

I had a real problem at work: we were constantly processing massive JSON array dumps — catalogs, analytics exports, ML datasets. The files ranged from hundreds of megabytes to tens of gigabytes.

The task was simple: split a giant JSON array into individual objects so they could be routed, chunked, or processed in parallel. That's it. No transformation, no querying by field name — just find where each {...} starts and ends.

And yet, we were doing json.Unmarshal → slice → json.Marshal. On a 10 GB file, the memory usage was absurd, and we spent more time fighting the GC than doing actual work.

At some point I realized: we don't need to understand the data to move it. We just need to find the boundaries.

The idea: boundary extraction

Instead of building an object tree (which is what every parser does — even fast ones like simdjson or sonic), you can treat JSON as a byte stream with structural markers and just scan for the edges of each object.

The logic boils down to a small state machine:

1. Nesting counter: { increments, } decrements.
2. String tracking: you need to know if you're inside "..." so you don't count braces inside string values.
3. Escape handling: a \" inside a string is not a real quote.
4. The boundary: when the nesting counter returns to 0 after being >0, you've found one complete object.

That's it. You don't look at keys. You don't look at values. You don't allocate anything. You return slices (memory views) into the original buffer.

Here's the conceptual core in Go (simplified, without the string-tracking):

gofunc findBoundaries(data []byte) []Chunk {
    var chunks []Chunk
    depth := 0
    start := -1
    for i, b := range data {
        switch b {
        case '{':
            if depth == 0 {
                start = i
            }
            depth++
        case '}':
            depth--
            if depth == 0 && start >= 0 {
                chunks = append(chunks, Chunk{Start: start, End: i + 1})
                start = -1
            }
        }
    }
    return chunks
}

Of course, this naive version is wrong — it doesn't handle strings, escapes, or nested arrays. But the principle is the key insight: you're not parsing, you're scanning.

Why this is fast

When you scan boundaries instead of parsing:

• Zero allocations in the hot path. You return data[start:end] — a slice of the original buffer. No new objects, no string copies, no map construction.
• Cache-friendly. Your working state is a couple of integers (depth counter, string flag). Everything fits in L1. The only memory access pattern is a linear sequential read.
• Pipeline-friendly. A state machine with predictable transitions is much kinder to the CPU's branch predictor than a parser that dispatches on dozens of token types.

Compare this to what a "real" parser does:

You're literally removing 80% of the work.

But how fast, really?

I got curious and decided to implement this properly — with a real string-aware state machine, correct escape handling, and a full AVX2 assembly kernel on amd64 for the hot scanning loop (processing 32 bytes per cycle, using SIMD bitmasks to classify structural characters in parallel).

Honestly, the results surprised even me:

>

The ~4.1 GB/s number is essentially limited by memory read bandwidth on my machine, not by the scanner's logic. The AVX2 kernel spends most of its time waiting for the next cache line to arrive.

When this is (and isn't) useful

Good fit:

• Splitting a huge JSON array into files/chunks for parallel processing
• Streaming: extracting objects from an io.Reader on-the-fly without loading the whole thing into RAM
• Proxying/routing: forwarding individual JSON objects from an array to different consumers
• Pre-processing for a real parser: find boundaries first, then parse each chunk on a separate goroutine

Bad fit:

• You need actual field values (you'll need a parser anyway)
• Your JSON isn't arrays-of-objects (this technique targets [{...},{...},...])
• Small files where the overhead of json.Unmarshal is negligible

The tradeoffs

Since I went the unsafe / raw assembly route for maximum performance, there are real costs:

• Platform-specific. The AVX2 path only works on amd64. You need a scalar fallback for ARM/other architectures.
• unsafe usage. Any time you avoid allocations by returning slices into a shared buffer, you need to be very careful about the buffer's lifetime. If the underlying []byte gets overwritten or GC'd while you still hold slices — boom.
• Not a validator. The scanner trusts that the input is valid JSON. It won't give you nice error messages about malformed data.

Closing thought

The mental shift was surprisingly simple: stop thinking "I need to parse this JSON" and start thinking "I need to find the boundaries in this byte stream." Once you reframe the problem, the solution practically writes itself — and the performance gap compared to full parsing is enormous.

Has anyone else gone down this path? I'm curious how people handle large-scale JSON splitting/routing in production — especially the streaming case where you can't load the full file.