Un linker Rust mai rapid cere un buget pe runnerul comun

O compilare care se termină mai repede pe o mașină liberă poate totuși să încurce alte lucrări pe un runner aglomerat. Schimbarea linkerului Rust din septembrie 2025 oferă un motiv bun să reevaluați resursele alocate unui runner CI comun. Adoptați noua opțiune implicită acolo unde se potrivește, dar judecați rezultatul după lucrările finalizate pe întregul runner și păstrați o cale explicită de revenire. Un pas de legare mai scurt nu dovedește că mai multe compilări simultane se vor termina mai repede.

Privind din noiembrie 2026, anunțul Rust 1.90 din 18 septembrie 2025 a făcut din LLD linkerul implicit pentru x86_64-unknown-linux-gnu. Delimitarea țintei contează. Versiunea nu a impus aceeași politică tuturor țintelor Rust, tuturor platformelor Linux sau tuturor seturilor de unelte personalizate. Inventariați ținta și configurația efectivă înainte să decideți dacă runnerul s-a schimbat în vreun fel.

Opțiunea implicită schimbă o etapă a compilării

Informarea din 1 septembrie explică faptul că rustc distribuit prin rustup include linkerul sub numele rust-lld. Tot ea avertizează că legarea paralelă poate fi nepotrivită în medii cu resurse limitate. Avertismentul ridică o întrebare operațională: câtă muncă poate susține mașina când mai multe compilări ajung simultan la etapele solicitante?

Compilarea, legarea și testarea ocupă porțiuni diferite dintr-o lucrare. Îmbunătățirea unei etape schimbă felul în care aceste porțiuni se suprapun între lucrări. Dacă mai multe compilări petreceau mult timp la legare, cu mai puține fire active, un linker mai paralel poate produce o solicitare mai scurtă, dar mai concentrată. Aceasta este o ipoteză despre programarea lucrărilor, dedusă din limita documentată. Nu este o măsurătoare pe un runner concret și nici afirmația că LLD consumă neapărat mai multă memorie în orice proiect.

Autorii Rust au raportat îmbunătățiri substanțiale pentru exemplul lor cu ripgrep. Sunt rezultate raportate de autori pentru o sarcină numită, nu un test AL+ sau o prognoză pentru alt depozit. Mesajul util este că etapa de legare merită atenție. Rezultatele nu pot spune unei echipe câte compilări proprii să admită pe o mașină care rulează deja teste și alte proiecte.

Alegeți unitatea care corespunde cozii

Pentru un runner comun, comparația propusă ar trebui să înceapă când lucrările devin eligibile și să se încheie când setul convenit este finalizat. Înregistrați așteptarea în coadă separat de execuție. Altfel, o configurație poate părea mai rapidă în graficul execuției fiecărei lucrări, deși oamenii așteaptă mai mult un loc liber. Ambele observații pot fi adevărate fără ca vreuna dintre măsurători să fie greșită.

Păstrați aceeași definiție a sarcinii. Folosiți aceeași revizie, țintă, același profil de compilare și aceeași politică de cache când comparați configurațiile. Separați recompilarea incrementală de compilarea de la zero, deoarece ponderea etapelor diferă. Amestecarea lor într-o medie neexplicată poate face ca o schimbare a sarcinii să pară o îmbunătățire sau o regresie a linkerului. Acestea sunt condiții propuse pentru evaluare; pentru articol nu s-a efectuat nicio compilare Rust și niciun experiment pe runner.

Observațiile despre resurse ar trebui să însoțească durata. Vârful consumului de memorie, presiunea asupra procesorului și lucrările eșuate sau repetate ajută la explicarea costurilor mutate în altă parte. O mașină care termină repede un test, dar oprește repetat lucrările vecine, servește alt obiectiv decât un runner destinat să golească sigur o coadă. Stabiliți criteriul de acceptare înainte să interpretați durata atrăgătoare.

Bugetul pentru execuții simultane privește întregul runner. O limită de paralelism pe compilare nu poate descrie singură solicitarea produsă de mai multe lucrări CI independente. Numiți nivelul care răspunde de admitere și includeți celelalte lucrări permise pe gazdă. Politica utilă poate însemna mai puține compilări simultane, o clasă separată pentru lucrările solicitante sau păstrarea limitei existente cât timp observați noua opțiune implicită. Sursele nu aleg politica în locul dumneavoastră.

Limitați revenirea la componenta vizată

Anunțul versiunii documentează -C linker-features=-lld drept opțiune de revenire la linkerul sistemului pentru această țintă. Păstrați exact această delimitare în documentația de revenire. Opțiunea ajută la izolarea unei probleme de linker; nu promite anularea altor schimbări ale compilatorului sau reproducerea tuturor proprietăților unui set de unelte anterior.

Atribuiți revenirea unui responsabil

Revenirea are nevoie și de un motiv, și de un responsabil. Dacă proiectul depinde de un comportament diferit între GNU ld și LLD, păstrați dovezile eșecului și urmăriți problema de compatibilitate. Dacă dificultatea este concurența pentru resurse, schimbarea admiterii poate fi mai utilă decât renunțarea definitivă la linkerul mai rapid. Identificați limita care a cedat înainte să transformați o setare de urgență într-o convenție neexplicată.

Fixarea versiunii uneltelor poate face comparația inteligibilă. O actualizare neînregistrată a compilatorului, un cache schimbat și alte resurse ale runnerului în aceeași evaluare lasă mai multe explicații plauzibile. Scopul este o decizie pe care alt responsabil de mentenanță o poate reconstitui, cu ținta aleasă și revenirea vizibile în documentație. Articolul nu propune schimbarea configurației și nici o rețetă executabilă de migrare.

Resursele libere schimbă decizia

Cel mai puternic contraargument este stația unui dezvoltator sau un runner dedicat cu resurse suficiente. Poate să nu existe un motiv serios pentru amânarea unei opțiuni utile până la un studiu amplu de capacitate. O verificare obișnuită de compatibilitate și observarea proiectului pot fi proporționale. Un avertisment despre gazde limitate nu dovedește o regresie pe cele fără asemenea limite.

Excepția întărește motivul de a defini mediul de operare. Același proiect poate câștiga pe o mașină dedicată și poate avea nevoie de altă limită de admitere într-un grup comun. Pentru dezvoltare software la comandă, includeți capacitatea runnerului și responsabilitatea revenirii în predare. Acceptați linkerul mai rapid când coada vizată se golește fiabil în bugetul de resurse și reevaluați concurența pe baza dovezilor despre acea coadă.