2026년 9월 Rust 컴파일러 성능 개선

AI 요약

Rust 컴파일러 성능을 다루는 지난 글 이후 두 달 동안 여러 최적화가 반영됐습니다. 2026년 7월 29일부터 9월 28일까지 측정한 벤치마크 629건 중 555건은 빨라졌고 74건은 느려졌습니다. 평균 벽시계 시간(wall time)은 4.57% 감소했으며, 여러 벤치마크에서 두 자릿수 개선도 나왔습니다.

Clippy와 LLVM

Clippy에 프로파일 기반 최적화(PGO)를 적용한 PR #159642는 대부분의 Clippy 벤치마크에서 시간을 줄였고, 가장 큰 개선 폭은 18%였습니다. PR #158734는 컴파일러가 사용하는 LLVM을 23으로 올렸습니다. 벤치마크 전체의 평균 벽시계 시간이 1.2% 감소했습니다.

새 borrow checker와 trait solver

새 borrow checker인 Polonius Alpha가 Nightly에서 활성화됐습니다. 기존 검사기보다 정밀해 기존에는 거부했던 유효한 프로그램을 받아들이지만, 일부 사례에서는 계산량이 늘어납니다. 인기 crate인 serde도 영향을 받았습니다. Jack Huey는 liveness 계산을 지연 실행해 serde의 명령어 수를 3~5% 줄였고, 다른 일부 벤치마크도 1% 미만 개선했습니다. 자료구조와 인라이닝을 조정한 후속 PR은 여러 벤치마크에서 대체로 1% 미만의 명령어 수 감소를 만들었습니다. Polonius Alpha에서 남은 성능 저하도 더 줄일 작업이 이어지고 있습니다.

새 trait solver도 Nightly에 들어갔습니다. 본문에서 잠시 사용한 ‘Penelope Hammertime’은 농담이며, 실제 이름은 작성자 후기에서 ‘Pineapple Häagen-Dazs’라고 밝힙니다. 새 solver 역시 일부 사례에서 느려지지만, Jana Dönszelmann이 성능 개선 작업을 자세히 정리했습니다. 작성자는 관련 PR 여러 건에서 특정 crate의 컴파일 시간을 50%, 25%, 15% 줄였고, 스트레스 테스트에서는 더 큰 개선을 냈다고 설명합니다.

할당과 데이터 흐름 분석 최적화

기여자 xmakro는 specialization graph를 만들 때 impl 처리 방식을 최적화해 전체 벤치마크의 평균 사이클 수를 1.58% 줄였습니다. incremental compilation 데이터 로딩과 의무(obligations) 처리 경로의 할당도 줄였으며, 일부 벤치마크에서 명령어 수가 최대 6%, 2% 감소했습니다. 기존·새 trait solver 선택 코드에서는 동적 디스패치를 정적 디스패치로 바꿔 불필요한 할당을 줄였습니다.

PR #160193은 데이터 흐름 분석의 제어 흐름 그래프(CFG) 순회 알고리즘을 바꿨습니다. 분석은 고정점에 도달할 때까지 반복하는데, 순회 방식에 따라 필요한 반복 횟수가 달라집니다. basic block이 18,000개 넘는 cranelift-codegen의 한 함수에서는 EverInitializedPlaces 분석이 효과 적용 함수를 150만 번 호출하던 것을 9만 번으로 줄였습니다. 해당 crate의 check 빌드 벽시계 시간은 약 30% 감소했습니다. 후속 최적화는 match-stress 벤치마크의 명령어 수를 17% 줄였습니다.

그 밖의 변경

컴파일러 기본 스택 크기를 늘린 PR #160535는 재귀가 깊은 경로에 넣어 둔 수동 스택 확장 장치 ensure_sufficient_stack을 제거했습니다. 여러 벤치마크에서 명령어 수가 줄었고, 가장 큰 감소 폭은 거의 3%였습니다. 성능 개선 PR 10개를 한꺼번에 묶은 rollup이 처음 만들어졌으며, 병합 뒤에도 개별 PR의 성능을 따로 측정해 예상한 효과가 났는지 확인합니다. AST를 HIR로 낮추는 코드의 정리 작업도 예상 밖으로 여러 벤치마크의 명령어 수를 최대 1.5% 줄였습니다.

작성자는 LLM의 분석 도움을 일부 PR에서 활용했지만, 코드와 글은 직접 작성했다고 밝혔습니다. 프로젝트 정책도 이를 요구한다고 덧붙였습니다. 다음 날부터 Hexcat에서 컴파일러 성능 최적화 프로젝트를 맡는다고 전했습니다.

Reddit 반응

• @u/Kivooeo1 — Hexcat에서 새 역할을 맡게 된 것을 축하합니다! 정말 기쁜 소식입니다!
• @u/kuldron — 이 글이 올라오길 늘 기대하고 있습니다 :)
• @u/VictoryMotel — 컴파일 시간은 대체로 어디에 쓰이나요? 이미 많이 최적화된 프로그램에서 두 달 동안 5% 줄인 건 큰 성과처럼 보입니다.
  • @u/nnethercote — 하나로 답할 수는 없습니다. 컴파일하는 프로그램과 빌드 설정에 따라 크게 달라집니다. 디버그와 릴리스 여부, 최적화 수준, LTO 같은 추가 기능 활성화 여부가 영향을 줍니다. 매크로 확장, trait 해석, borrow checking, LLVM 백엔드가 병목일 때도 있습니다.
  • @u/VictoryMotel — 반복 작업이 중요하고 최적화가 필요 없는 디버그 빌드에서는 어떤가요?
  • @u/Farlo1 — 우리 팀이 맡은 실행 파일은 대부분 C/C++인데, 개발자 컴퓨터와 CI, 릴리스 빌드에서 하루에도 수천 번 컴파일됩니다. CPU 사용량을 5% 줄이면 우리처럼 비교적 작은 조직도 연간 수만 달러를 아낄 수 있습니다. Google 규모라면 수천만 달러가 될 수도 있습니다.
  • @u/VictoryMotel — 제 댓글과는 전혀 다른 이야기이고 관련도 없습니다.
  • @u/Farlo1 — 제가 댓글을 잘못 이해했나 봅니다. 두 달 만에 5% 줄인 성과가 크지 않다는 뜻으로 받아들였습니다. 죄송합니다!

원문: nnethercote.github.io / 번역·요약: Trawling