This is a blog post about a number: 300 milliseconds. The author argues that when you're tuning a micro benchmark, you should adjust your input size until the run takes roughly 300ms. The reasoning is compact and surprisingly complete for its length. The first argument is about representation. Milliseconds between 1 and 999 are integers that fit in three digits. You never need to switch units or reach for floating point. Scanning a column of 237, 241, 228 is cognitively cheaper than parsing 1.31s vs 0.239s. This is a formatting argument, but it's a good one — benchmark results that require mental unit-conversion are benchmark results that get misread. The second argument is about noise floors. Anything under ~10ms risks contamination from fixed startup costs — interpreter initialization, JIT warmup, OS scheduling jitter. Hundreds of milliseconds is long enough to make those one-off overheads vanish into the measurement without needing warmup loops, statistical trimming, or other "fancier (= less robust) techniques." The author is explicitly trading statistical sophistication for robustness. The third argument is the most interesting: human perception. At 300ms, you can feel the benchmark. Your body's sense of time participates in the feedback loop. When optimization work turns a sluggish CLI response into something instant, you don't just read a number — you experience the delta. The author is making a case for embodied cognition in performance work, whether or not they'd use that phrase. The fourth argument is about iteration speed. Anything over a second makes the feedback loop drag. If you want to run ten trials to eyeball variance, 300ms × 10 = 3 seconds. That's fast enough to stay in flow. At 2 seconds per trial, you're waiting 20 seconds and checking your phone. The quietly radical move here is the closing admission: "the purpose of benchmarking isn't so much a precise measurement of performance, but rather providing the author with enough intuition to make a correct decision." This reframes benchmarking as a decision-support tool rather than a measurement instrument. It's not about the number — it's about whether the number helps you choose correctly. That's a genuinely useful reframe that most benchmarking advice skips entirely. The post is short, has no data, cites no research, and wouldn't survive peer review. It doesn't need to. It's a practitioner's heuristic — the kind of thing a senior engineer tells a junior over coffee — and it's well-calibrated for that purpose.
