Bí quyết tăng tốc trình biên dịch Rust trong tháng 9 năm 2026

Trình biên dịch Rust vừa trải qua hai tháng với nhiều cải tiến hiệu năng đáng kể. Bài viết mới nhất từ một nhà phát triển tham gia trực tiếp vào dự án đã điểm lại toàn bộ tiến độ, từ những tối ưu nhỏ lẻ cho đến các thay đổi kiến trúc lớn.

Bức tranh tổng thể

Trong giai đoạn từ ngày 29/7 đến 28/9/2026, kết quả đo đạc cho thấy mức giảm thời gian biên dịch trung bình là 4,57%. Với một dự án quy mô như Rust, đây là con số rất ấn tượng chỉ trong vòng hai tháng.

Trong tổng số 629 phép đo benchmark, có 555 phép đo cải thiện và chỉ 74 phép đo bị chậm đi. Nhiều benchmark thậm chí đạt mức giảm hai chữ số phần trăm. Cách gọi kỹ thuật của kết quả này là "một biển xanh" — ám chỉ gần như toàn bộ các chỉ số đều theo chiều hướng tích cực.

Đây là minh chứng cho thấy cộng đồng Rust đang duy trì được đà tối ưu hiệu năng rất đều đặn.

Những đóng góp nổi bật

rustdoc

Trước đó, Noah Lev đã đạt được những bước tiến lớn về tốc độ cho rustdoc. Anh mới đây chia sẻ một bài viết giải thích chi tiết cách thực hiện, và đây là nội dung đáng đọc với bất kỳ ai quan tâm đến tối ưu công cụ tài liệu.

Clippy

Trong PR #159642, Jakub Beránek đã bật PGO (Profile-Guided Optimization) cho Clippy, giúp cải thiện thời gian thực thi trên hầu hết các benchmark, trường hợp tốt nhất đạt 18%.

Cập nhật LLVM

PR #158734 do Nikita Popov thực hiện đã nâng phiên bản LLVM mà trình biên dịch sử dụng lên LLVM 23. Kết quả là mức giảm thời gian trung bình 1,2% trên toàn bộ benchmark — con số nghe có vẻ nhỏ nhưng thực sự đáng nể với một PR đơn lẻ.

Borrow checker mới: Polonius Alpha

Polonius Alpha, borrow checker thế hệ mới, đã được bật trên kênh Nightly. Nó chính xác hơn borrow checker hiện tại và chấp nhận một số chương trình hợp lệ mà công cụ cũ từ chối.

Đổi lại, Polonius Alpha thực hiện nhiều tính toán hơn, khiến thời gian biên dịch tăng lên trong một số trường hợp, bao gồm cả crate phổ biến serde. Rất may, Jack Huey đã vào cuộc:

• PR #161938: Biến một số phép tính liveness thành lazy, giảm 3-5% số lệnh cho serde.
• PR #163027: Điều chỉnh cấu trúc dữ liệu và tinh chỉnh inlining, giảm dưới 1% số lệnh trên nhiều benchmark.

Vẫn còn việc phải làm để xử lý các trường hợp chậm đi còn lại của Polonius Alpha, nhưng cần lưu ý rằng "biển xanh" cho thấy các ảnh hưởng tiêu cực này đã bị lấn át bởi vô số cải tiến khác.

Trait solver mới

Trait solver thế hệ mới cũng đã được bật trên Nightly. Tương tự borrow checker mới, nó chậm hơn trong một số ít trường hợp. Jana Dönszelmann đã viết một bài rất chi tiết về nỗ lực cải thiện hiệu năng của solver này.

Tác giả bài viết cũng đóng góp nhiều PR cho hướng đi này, trong đó có #160479, #160605, #160801, #160892, #161077 và #161211. Một số PR giảm thời gian biên dịch rất mạnh với các crate đặc thù: 50%, 25%, 15%, thậm chí hơn thế trên một bài kiểm tra chịu tải.

Đóng góp của xmakro

Thành viên mới xmakro liên tục có những cải tiến chất lượng:

• #157281: Tối ưu xử lý impl khi xây dựng đồ thị specialization, giảm trung bình 1,58% chu kỳ CPU trên toàn bộ benchmark — rất lớn với một PR đơn lẻ.
• #158059: Tối ưu việc nạp dữ liệu biên dịch tăng dần, trường hợp tốt nhất giảm 6%.
• #160473: Loại bỏ một số cấp phát trong đường xử lý obligations nóng, tốt nhất giảm 2%.
• #160268: Chuyển từ dynamic dispatch sang static dispatch cho mã chọn trait solver, giảm chủ yếu dưới 1%.

Phân tích luồng dữ liệu

PR #160193 thay đổi thuật toán duyệt CFG dùng cho các phân tích dataflow. Hầu hết mã nguồn không bị ảnh hưởng, nhưng crate cranelift-codegen có một hàm khổng lồ với hơn 18.000 basic block. Thuật toán cũ cần 1,5 triệu lần gọi để đạt điểm cố định cho phân tích EverInitializedPlaces; thuật toán mới chỉ cần 90.000 lần. Kết quả là giảm khoảng 30% thời gian biên dịch cho crate này.

PR #160033 tiếp tục tối ưu EverInitializedPlaces bằng cách không theo dõi dữ liệu không cần thiết cho các projection, giảm 17% số lệnh trên benchmark match-stress.

Các thay đổi lặt vặt đáng chú ý

• #160535: Chris Denton tăng kích thước stack mặc định của trình biên dịch, cho phép loại bỏ cơ chế mở rộng stack thủ công ensure_sufficient_stack. Trường hợp tốt nhất giảm gần 3%.
• #160506: Dự án lần đầu tiên phải gộp nhiều PR tối ưu hiệu năng vào một "rollup" để tránh tắc nghẽn hàng đợi merge. Một vấn đề đáng mừng.
• #162859: Rollup khác chứa bốn PR tối ưu hiệu năng.
• #162747: Một PR dọn dẹp mã chuyển AST sang HIR, không kỳ vọng cải thiện hiệu năng, nhưng lại giảm tới 1,5% số lệnh trên nhiều benchmark.

Ghi chú về trí tuệ nhân tạo

Tác giả thừa nhận các mô hình ngôn ngữ lớn (LLM) đã trở nên rất giỏi ở một số dạng phân tích nhất định và đã hỗ trợ hữu ích cho một vài PR trong số này. Tuy nhiên, anh vẫn tự viết toàn bộ mã và văn bản của mình, vì đó là nguyên tắc cá nhân và cũng là yêu cầu của dự án.

Tình hình công việc

Tác giả sẽ bắt đầu làm việc tại Hexcat cho mục tiêu dự án tối ưu hiệu năng trình biên dịch. Anh gửi lời cảm ơn tới Mara Bos, Predrag Gruevski và những người khác đã giúp điều này thành hiện thực.

Lời bạt

Cần đính chính vui rằng tên thật của trait solver mới không phải "Penelope Hammertime" như đùa trong bài — tên chính thức của nó là Pineapple Häagen-Dazs.