March 23, 2026
Find All? Find a chair
The quadratic problem nobody fixed
“Find All” faceplant: devs say regex is secretly slow, commenters fight over AI vibes
TLDR: A new post argues that “find all” searches in regex can slow down dramatically on big text, despite “fast” claims for single matches. Commenters duel over whether the post is human or AI‑tinged and debate if RE#’s two‑pass trick could fix it, spotlighting a real performance gotcha for everyday searches.
A bombshell blog claims the humble “find all” search in regular expressions—those text patterns programmers love—has been quietly chewing time for decades. The author says engines that brag about “linear time” are fine for one match, but slow down dramatically when asked to find every match, turning big files into time sinks. That sparked two immediate reactions: techies clutching pearls over the quadratic slowdown, and the internet’s new sport—spot the AI author.
On one side, readers like mkehrt and IshKebab swear the post “reads human,” while cubefox suspects it was “at least ‘enhanced’ with an LLM,” citing an alarming number of dashes. halperter plays referee: human-written, but hey, could be lying. Meanwhile, the practical crowd asks the real question: can RE#’s touted two‑pass fix just be adopted everywhere? Some point to docs from the Rust and Go worlds saying that when you iterate over all matches, worst‑case slowdown is unavoidable unless you change semantics—cue groans.
Jokes flew fast: people riffed on the post’s “heat death of the universe” line and memed the demo pattern that scans for an ‘a’ in a sea of ‘b’s—“death by a thousand b’s.” Others griped about flags and downvotes, because it’s not a Hacker News thread until someone calls the moderation “disgraceful.” Verdict: real problem, real drama, and nobody agrees on whether the fix—or the author—is fully human.
Key Points
- •Linear-time guarantees in modern regex engines apply only to single-match searches; iterating over all matches can devolve to O(m·n²).
- •Rust regex crate documentation explicitly states worst-case quadratic time for iterators and suggests stopping after the first match as mitigation.
- •A concrete pattern (.*a|b) on a b-only string shows triangular-sum behavior, producing O(n²) work for n matches.
- •Russ Cox documented this issue in 2009; early tools like awk used a quadratic loop-around-DFA approach for leftmost-longest matching.
- •Benchmarks (rebar) show throughput roughly halves when input size doubles in worst-case scenarios across RE2, Go, and Rust engines.