February 3, 2026
Delete code, ignite comments
When rust ≠ performance. a lesson in developer experience
Dev deletes code, app gets 20x faster—Rust fans spar
TLDR: An Oxen dev sped up a slow process 20x by removing extra data handling and avoiding a shared database lock. The comments erupted over whether Rust guarantees speed, with many saying smart design—not the language—is what makes software fast, and some calling the write-up frustratingly short on details.
An Oxen engineer just pulled off a rare flex: a whopping 20x speedup by… deleting code. The “commit” step went from over 50 minutes to a few, after realizing threads were fighting over the same database lock—too many pieces trying to open the same door at once. The fix? Strip out extra data copying and repeated database opens, and suddenly everything flies. Less code, more go. Cue the comments: some cheered the simplicity, while others called the post light on details. One reader joked the write-up itself felt “trimmed” when they hit a mid-sentence cliffhanger: “Reduced your what?” The bigger brawl: Rust is not a magic speed button. Skeptics blasted the headline as clickbait and reminded everyone that performance comes from smart design, not just picking Rust. Fans defended Rust’s safety and tooling, but even they admitted brainpower spent on complex features can sap time from making things fast. Meanwhile, the crowd memed it up: “delete code to go brrr,” “Locks vs Rocks,” and “rust ≠ performance, design = performance.” For the curious, the engineer used samply to profile and shipped a tidy PR. Bonus aside: RocksDB loves parallel writes, not reads—another twist in this speed saga.
Key Points
- •Oxen’s “commit” operation was unexpectedly slow (>50 minutes) compared to “add” (~1 minute for 1M files).
- •Profiling with Samply showed over 90% of commit time spent waiting on a lock in the staging RocksDB.
- •Redundant .clone() calls and repeated db.open() across layers exacerbated thread contention.
- •A simplifying code change removed redundant data handling, yielding approximately a 20× speedup.
- •RocksDB is better suited to parallel writes than parallel reads, contributing to the observed overhead.