Dan Luu reports a 7% ripgrep speedup after minutes of prompting

Dan Luu reports that a coding agent achieved a 7% speedup on ripgrep by splicing ahead-of-time compilation into an experimental regex engine, with simple long-running searches improving by 2x to 4x, after only a few minutes of human prompting. Luu argues that coding agents have made workload-specific optimization economical, shifting the bottleneck to benchmarks, verification, and production reliability. He also notes that his experimental engine FRE became overfit to the public Rebar benchmark suite until he disclosed a holdout set, highlighting the need for human judgment in optimization work.

Dan Luu reports a 7% ripgrep speedup after minutes of prompting Dan Luu argues coding agents have made once-specialized optimization cheap enough to customize software for each workload. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: Dan Luu https://danluu.com/perf-opt/ Why it matters Coding agents could make workload-specific optimization economical for ordinary teams. Benchmarks, verification and production reliability become the binding constraints. Dan Luu @danluu https://x.com/danluu/?ref=runtimewire used a coding agent to splice ahead-of-time compilation into an experimental regex engine and run it alongside ripgrep, producing a reported 7% speedup https://danluu.com/perf-opt/?ref=runtimewire on representative holdout queries where the compiler was enabled. A few simple, long-running searches improved by 2x to 4x. Luu says his human contribution took a few minutes of prompting. The performance test is narrow and self-reported. The larger result in Luu's August 22 essay https://danluu.com/perf-opt/?ref=runtimewire is economic: coding agents have reduced the labor required to attempt specialized performance work, including experiments that once demanded days from an engineer familiar with compilers, processor behavior and benchmarking. Small wins become rational when testing an idea costs a few minutes rather than a week. Luu points to his experience with CPU microcode, CPU verification and search-engine indexing as evidence of what this work used to cost. He worked on BitFunnel, a Bing search index specialized for constant, fast text ingestion, primarily to reduce operational costs. Its published benchmarks reported query throughput that varied by workload. Luu says the kinds of optimization projects he once weighed in person-days can now be attempted much more cheaply. His current argument comes from an engineer who has repeatedly made the old build-versus-buy calculation for low-level optimization. Cheap experiments still need expensive judgment Luu built FRE https://github.com/danluu/fre?ref=runtimewire , his experimental regex engine, by letting an agent loop on performance work for a month. The first result exposed the central weakness in autonomous optimization: FRE became heavily overfit to the public Rebar benchmark suite. The agent improved its behavior on unseen queries only after Luu disclosed that a holdout benchmark existed. That episode puts a hard boundary around the claim that anyone can become a performance engineer by typing instructions. Agents can generate code, perform invasive refactors and run large numbers of experiments. They still need a human to choose the workload, protect the holdout set, detect benchmark gaming and decide whether a measured gain matters in production. The ripgrep result reflects that division of labor. Luu cared about searches that consume seconds or minutes, so he accepted the cost of compiling in another thread before switching to native code. That trade would be counterproductive for short queries. His own query history supplied the workload, while a separate set of representative queries checked whether the optimization generalized. The resulting 7% gain will not rescue a slow product by itself. It shows why optimization backlogs may change. In his essay, Luu describes weighing prospective 2% performance gains against the person-days required to implement and verify them. Coding agents can cut the cost of testing those ideas far enough that teams attempt many more of them, then keep the handful that survive measurement. Michael Malis is making the database-sized version of the bet The more ambitious example comes from Michael Malis @mmalisper https://x.com/mmalisper?ref=runtimewire , who created pgrust https://pgrust.com/?ref=runtimewire , an experimental PostgreSQL rewrite in Rust, with Jason Seibel. Malis went directly from high school to Heap in 2015, where he says he managed performance for a PostgreSQL cluster holding more than a petabyte of data. malisper.me https://malisper.me/about-me/?ref=runtimewire Malis began pgrust in early April 2026 as a from-scratch PostgreSQL rewrite in Rust. In an April 20 account of the project https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-ai/?ref=runtimewire , he reported producing roughly 250,000 lines of code in two weeks and passing about one-third of PostgreSQL's regression tests. He eventually ran as many as 17 coding agents in parallel, breaking features into small, test-passing slices to reduce merge conflicts. malisper.me https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-ai/?ref=runtimewire The pgrust repository https://github.com/malisper/pgrust?ref=runtimewire now says the project passes all 46,066 queries in PostgreSQL's default regression suite. Its redesigned internals include a vectorized, push-based JIT executor, thread-based concurrency, a query scheduler, columnar storage and a built-in out-of-memory killer. The supplied repository snapshot showed 204 GitHub stars. github.com https://github.com/malisper/pgrust?ref=runtimewire Those numbers establish activity and compatibility work, rather than production readiness. The maintainers explicitly warn users against storing important data in pgrust, say it still contains many bugs and note that existing PostgreSQL extensions do not work. Passing a regression suite also leaves crash recovery, security, operational behavior and long-running reliability to be proved. github.com https://github.com/malisper/pgrust?ref=runtimewire Luu quotes Malis making the economic case behind the project: "LLMs have lowered the barrier to entry and made it much easier to write a JIT compiler." Malis argues that implementation cost historically kept JIT compilers out of programs that could benefit from them, and describes pgrust as an attempt to apply the same reasoning to database development. danluu.com https://danluu.com/perf-opt/?ref=runtimewire Software fitted to the workload Marc Brooker, an AWS vice president and distinguished engineer, described the likely destination as dynamic software fitted to a particular workload rather than a broad class of workloads. Luu's ripgrep experiment is a small version of that idea: optimize for the searches one user or one fleet actually runs, using its own history as the training workload. Marc Brooker on workload-specific software https://x.com/MarcJBrooker/status/2089545628607255026?ref=runtimewire That approach creates obvious failure modes. A customer-specific optimizer can overfit yesterday's traffic, silently regress after a workload changes or optimize a benchmark that omits the expensive edge cases. Generated low-level code also expands the amount of software that must be tested, audited and maintained. Agents make code cheaper to produce; they do not make incorrect machine code cheaper to operate. Luu's essay still marks a useful change in the software cost curve. Performance work no longer needs to begin with a requisition for a compiler specialist. A founder or infrastructure engineer can run the first experiment, measure it against a guarded workload and discard it before a specialist would have finished estimating the project. The winners will be teams with good benchmarks and the discipline to throw away impressive-looking code when the holdout says it is slow.