December 19, 2025
Knuth quote cage match
Performance Hints – Jeff Dean and Sanjay Ghemawat
Two Google legends say small speed gains matter; the internet fights about it
TLDR: Jeff Dean and Sanjay Ghemawat released practical speed-up tips, stressing that small improvements matter. The community split: some cheer cost-saving gains, others warn against over-optimizing and worshiping C++; memes and Rust vs C++ skirmishes ensued, highlighting why performance choices shape both bills and user experience.
Google’s mythic duo Jeff Dean and Sanjay Ghemawat just dropped a plain-English playbook on squeezing more speed out of code, arguing that small gains add up and that you should pick the faster option when it doesn’t make code harder. They quote Donald Knuth to push back on the overused “premature optimization is the root of all evil” line. The doc sticks to single-program tips (no cloud clusters, no AI chips), with click-to-reveal code and a few Google-only tidbits.
Cue the internet fireworks on Hacker News. One camp is cheering: “12% is huge at scale—ship it.” Another clutches readability, warning against turning simple code into speed-obsessed spaghetti. Wallet-watchers say cloud bills are a performance tax, while pragmatists argue most apps are slow because of databases, not code.
There’s the usual Rust vs C++ cage match, plus chuckles about “Jeff Dean Facts” (“he optimizes, my coffee compiles faster”). Some bristle at examples using Google-only tools (“cool, but can we run this at home?”). Others love the real code changes and want more. The vibe: big respect for the legends, mixed with loud skepticism and meme-fueled debates over when to optimize.
Key Points
- •Jeff Dean and Sanjay Ghemawat authored a document on general software performance tuning, largely illustrated with C++ examples.
- •The document focuses on single-binary optimization and explicitly excludes distributed systems and ML hardware performance tuning.
- •Examples include self-contained code fragments, some referencing internal Google abstractions.
- •The authors argue for considering performance early, citing Knuth to value modest improvements and avoid flat profiles.
- •They recommend choosing faster alternatives when readability isn’t harmed and developing estimation intuition to judge complexity trade-offs.