August 5, 2026
No Ifs, Just Chaos
Branchless Rust: Making a Filter 4x Faster by Removing an If
A tiny code tweak made Rust fly, and the comments instantly split into hype, doubt, and AI shade
TLDR: A Rust coder says removing a single yes-or-no check made a hot part of their program run about four times faster, showing how tiny code choices can have huge effects. Commenters loved the speed story, questioned whether it works everywhere, and one loudly accused the post of being AI-written.
A Rust developer changed one tiny decision point in a number-filtering program and suddenly got a speed boost big enough to make performance nerds do a double take. The basic idea, explained in the original post, is surprisingly simple for non-experts: when a computer has to keep asking itself “yes or no?” at high speed, that hesitation can slow things down badly. Remove that hesitation, and the code can move way faster. On one test, the middle-case workload was oddly the slowest, and that mystery is what sent the comments into full detective mode.
And honestly? The comments are the real show. Some readers were delighted, calling this the fun part of programming and swapping stories about their own tuning wins. One commenter was basically revving their engine, saying they now want to try the same trick in a Rust JSONLogic project. Others took the cautious-parent route: cool explanation, but do we really want to go this deep into the CPU’s weird little mind, and would the same trick work across different chips? Then came the classic internet curveball: “Would PGO figure this out?”—a very on-brand attempt to outsource the pain to the compiler.
But the spiciest moment was pure comment-section chaos: one reader bluntly declared the article “100% AI written,” dragging the writing style as too wordy to be useful. So the mood ended up being a perfect tech-thread cocktail: admiration, curiosity, mild skepticism, and one drive-by roast that got more attention than half the benchmark chart.
Key Points
- •The article benchmarks a Rust filter over one million random `f64` values using thresholds that retain about 1%, 25%, 50%, 75%, or 99% of elements.
- •Criterion results on an Intel i7-10875H show the 50% retention case is the slowest at about 3.94 ms, while the 99% case is faster at about 1.49 ms.
- •A preallocated version using `Vec::with_capacity(input.len())` improves the 50% case only slightly, from 3.94 ms to 3.87 ms.
- •The article attributes the main slowdown to CPU branch prediction rather than vector reallocations.
- •It explains that unpredictable branching at a 50% keep rate causes frequent pipeline flushes, while highly predictable 1% and 99% cases are much faster.