November 12, 2025
Compiler goes keto
Making the Clang AST Leaner and Faster
Clang puts C++ on a diet; builds get faster, but some fear more template chaos
TLDR: Clang 22 trims how it stores types, speeding real builds by up to 7%. Fans celebrate faster compiles, skeptics warn it could fuel more template bloat, and power users demand caching—turning a clever optimization into a wider debate about C++ speed and sanity.
Clang—the engine that turns C++ code into apps—just went on a speed diet. A new refactor packs type details tighter and cuts wasted overhead, delivering real wins: ~7% faster on a nasty stdexec test and ~5% for Chromium. Translation for non-compiler folks: the team removed a clunky wrapper and stored the info where it counts, so your builds start sooner and wait less.
Cue the comments: some are popping champagne. “Awesome improvement,” cheered gnusi, as devs dream of shorter coffee breaks. But the hot take brigade arrived fast. Reactordev came in swinging: “Templates are abhorrent abominations,” blasting modern C++ as a hairball mess and thanking Clang for shaving off pain without fixing the root problem. Jiehong tossed a spicy prediction: faster compiles might encourage even more template-heavy code, making the monster harder to tame.
Meanwhile, performance diehards like wild_pointer aren’t satisfied—speed is good, but they want the next leap: fine-grained caching. They dropped a link to the LLVM RFC for content-addressed storage here, basically asking, “Great diet—now bring the turbo.”
Memes flew: “Clang keto,” “templates go brrr,” and “my coffee is getting cold.” Love it or loathe it, this change ships in Clang 22 soon, and the community is split between applause, doom-prophecies, and demands for even bigger speed boosts.
Key Points
- •A large patch to Clang’s AST reduces memory footprint and type creation/uniquing costs, improving compile times for templated C++.
- •stdexec’s slowest test saw a 7% build-time reduction; Chromium builds improved by 5%.
- •ElaboratedType nodes have been removed; elaboration and qualifiers are stored directly in RecordType.
- •Qualifiers are tail-allocated and elaboration uses previously unused bits, shrinking node size and removing an indirection.
- •NestedNameSpecifier chains previously required multiple allocations and uniquing; the new representation reduces allocation and hash lookups.