Překladač Rustu zrychlil za osm měsíců o 5,6 %. Polovinu z toho udělal jediný nástroj

Nicholas Nethercote pracuje na rychlosti překladače Rustu deset let a jednou za čas sepíše, co se za tu dobu povedlo. Poslední díl vyšel 31. července 2026 a pokrývá období od 3. prosince 2025 do 29. července 2026.

Souhrnné číslo zní 5,59 % – o tolik se v průměru zkrátila doba běhu měřených úloh. Zhruba polovinu toho zisku ale nepřinesl samotný překladač, nýbrž rustdoc, nástroj na generování dokumentace: ten zrychlil v průměru o 37,92 %. Když se rustdoc z výpočtu vyjme, zbude 2,90 %.

To je poctivé rozlišení, které se v podobných shrnutích často ztrácí. Kdo překládá kód a dokumentaci negeneruje, těch pět a půl procenta nepocítí.

Kde se vzalo těch skoro čtyřicet procent

Za největší kus stojí čtyři změny Noaha Leva, které omezily práci při zpracování bloků impl. Autor shrnutí u nich přiznává, že jim do podrobností nerozumí – a cituje Guillauma Gomeze. Ten to shrnul větou, kterou tu překládáme: „to všechno proto, že někdo narazil na podivnou chybu při používání rustdocu.“

Druhá změna je vděčnější na vysvětlení. Jakub Beránek přidal měřicí úlohy rustdocu do trénovací sady pro PGO – optimalizaci, při které se program nejdřív spustí, změří se, kudy běh doopravdy chodí, a teprve pak se přeloží podle toho. Rustdoc díky tomu zrychlil v průměru o 2,85 %, v nejlepším případě přes šest procent. Nethercote k tomu píše, že se PGO nastavuje obtížně, ale umí hodně změnit – a že na trénovací sadě záleží.

Třetí je jeho vlastní: změna způsobu, jakým rustdoc řadí bloky impl. Dřív se řadily dlouhé vygenerované řetězce HTML, teď se řadí podle kratší textové podoby jména. Sloučeno 31. května 2026, dvacet přidaných a dvacet šest odebraných řádků; v nejlepším případě to ubralo přes šest procent instrukcí.

Většina volání nedělala nic

Nejnázornější případ se týká Clippy, nástroje na kontrolu stylu a častých chyb. Clippy má stovky samostatných kontrol a každá z nich může obsloužit několik desítek událostí – check_item, check_stmt, check_expr a další. Při průchodu stromem se pro každý uzel zavolá příslušná metoda u každé kontroly.

Jenže většina kontrol si všímá jen jedné události, často jediné. Zbylá volání tedy nedělají nic – a přesto je každé z nich virtuální, tedy takové, u kterého se cíl skoku hledá až za běhu. Vývojář vystupující jako xmakro našel způsob, jak průchody spojit tak, aby se prázdné metody nevolaly vůbec.

Nethercote zkoumal tentýž problém současně a přišel s vlastním řešením. Nesloučilo se – bylo funkčně rovnocenné, ale zasahovalo do kódu víc. Změřil u něj ale podrobnosti, které stojí za citaci: doba běhu Clippy klesla ve většině případů o 10 až 30 %, chybné předpovědi skoků o 20 až 80 % na skutečných příkladech a o 97 % na jednom zátěžovém testu.

Sám k tomu dodává, že po deseti letech práce na výkonu překladače zkoušel optimalizovat Clippy poprvé, našel vážný problém, opravil ho – a pak zjistil, že ho někdo o pár dní předběhl.

Osm bajtů nad mezí

Druhý případ je ještě konkrétnější a týká se nového řešitele takzvaných traitů, tedy té části překladače, která rozhoduje, jestli typ splňuje požadované vlastnosti. Vývojář lcnr upozornil na dva balíčky, kde nový řešitel běžel výrazně pomaleji.

Nethercote je proměřil a zjistil, že skoro polovinu času tráví překladač ve funkci memcpy, tedy prostým kopírováním paměti. Příčina: horké pole obsahovalo prvky o velikosti 136 bajtů. LLVM, které rustc používá na generování strojového kódu, přepíná u hodnot nad 128 bajtů z přímých instrukcí právě na volání memcpy.

Oprava udělala dvě věci: vyhnula se dvěma třetinám přesunů a zmenšila typ na 104 bajtů, aby zbylé přesuny pod tu mez spadly. U dvou nejhorších balíčků to zkrátilo dobu běhu o 40 %. Sloučeno 28. července 2026, sedmdesát tři přidaných řádků.

Naše hodnocení: tohle je poučnější než souhrnné procento. Osm bajtů nad prahem, o kterém programátor v Rustu běžně neuvažuje, protože ho určuje až vrstva pod ním.

Co ještě a kdo

U přírůstkového překládání – kdy se po úpravě nepřekládá všechno znovu – přibylo šest drobnějších změn od vývojářů vystupujících jako Zalathar, zetanumbers a xmakro; nejlepší z nich ubraly 5 až 10 % instrukcí.

Nový řešitel traitů se chystá na vydání a na jedné z měřicích úloh klesla doba běhu za tři měsíce z 27 sekund pod jednu. Nethercote zároveň upozorňuje, že o většině té práce sám nemá přehled.

Za zmínku stojí i to, kdo změny psal. Kromě dlouholetých přispěvatelů se objevují dvě nová jména: už zmíněný xmakro a arya dradjica, autorka experimentálního překladače Rustu zaměřeného na rychlost, která na práci nově dostává finanční podporu a věnuje se rozbalování maker.

Zdroje

• Nicholas Nethercote: How to speed up the Rust compiler in July 2026, 31. 7. 2026
• rust-lang/rust #160005 — Avoid excessive memcpys with the new solver, sloučeno 28. 7. 2026
• rust-lang/rust #157179 — rustdoc: optimize impl sorting, sloučeno 31. 5. 2026

Čísla u obou změn v seznamu jsou ověřená proti rozhraní GitHubu, ne jen proti shrnutí: autor, datum sloučení i rozsah zásahu sedí.