uv thêm tính năng khử trùng lặp toàn bộ file trong bộ nhớ cache wheel

uv, trình quản lý package Python được viết bằng Rust và nổi tiếng với tốc độ vượt trội, vừa công bố một cải tiến quan trọng trong PR #21327 trên GitHub: khử trùng lặp (deduplication) ở cấp độ file cho toàn bộ bộ nhớ cache wheel. Thay vì chỉ lưu trùng lặp ở cấp độ wheel như trước đây, uv giờ đây sẽ lưu mỗi file riêng lẻ dưới dạng hàm băm BLAKE3, giúp tiết kiệm khoảng 10% dung lượng cache — một con số đáng kể cho các dự án có nhiều dependency chồng chéo.

Cơ chế hoạt động mới

Trước đây, uv hỗ trợ content-addressed caching nhưng chỉ ở cấp độ wheel — nghĩa là nếu bạn tải cùng một wheel từ hai nguồn khác nhau, chúng sẽ dùng chung một mục cache. Tuy nhiên, các file bên trong hoặc giữa các wheel khác nhau hoàn toàn không được khử trùng lặp.

PR này thay đổi điều đó bằng cách áp dụng khử trùng lặp ở cấp độ file:

• Mỗi file được lưu dưới BLAKE3 hash trong một bucket mới có tên files-v0.
• Các file này được hardlink vào vị trí gốc của chúng trong archive-v0, nên bước cài đặt không thay đổi gì.
• Quá trình dọn dẹp cache sẽ xóa các đối tượng file khi số lượng hardlink giảm xuống còn một.

Kết quả tiết kiệm ấn tượng

Theo bảng dữ liệu được tác giả Charlie Marsh công bố trong PR, mức tiết kiệm phụ thuộc vào loại file được chọn để khử trùng lặp:

• File thực thi và thư viện native: tiết kiệm 275.7 MiB
• File payload ≥ 10 MiB: tiết kiệm 235.0 MiB
• File payload ≥ 1 MiB: tiết kiệm 279.7 MiB
• File payload ≥ 100 KiB: tiết kiệm 353.4 MiB
• File payload ≥ 10 KiB: tiết kiệm 475.7 MiB
• File payload ≥ 1 KiB: tiết kiệm 537.4 MiB
• Toàn bộ file payload: tiết kiệm 545.2 MiB — tương đương khoảng 10% dung lượng cache trên máy cá nhân của tác giả

Các thử nghiệm và đánh giá hiệu suất

Trước khi chốt phương án này, tác giả đã thử nghiệm nhiều hướng tiếp cận khác nhau:

"Tôi đã thử lưu tất cả file ở dạng không thực thi rồi áp dụng cờ thực thi khi cài đặt để có thể hardlink trong lúc giải nén. Tuy nhiên, điều đó buộc chúng tôi phải sao chép mọi file thực thi khi cài đặt vì hardlink dùng chung mode — và kết quả là chậm hơn."

Một hướng khác là tìm nạp trước central directory của file ZIP để biết file nào có quyền thực thi ngay từ lúc giải nén, nhưng cách này cũng chậm hơn do phát sinh thêm các yêu cầu HTTP.

Cuối cùng, tác giả kết luận: "Tôi nghĩ những gì chúng tôi đang có là tốt." Đặc biệt, nếu kết hợp với PR #21340, tổng thể tốc độ còn nhanh hơn trước đây.

Nhận xét từ cộng đồng

Reviewer Zanieb đã đặt câu hỏi về khả năng tương thích với reflinks (liên kết copy-on-write trên một số hệ thống file như Btrfs hoặc APFS), và cũng góp ý rằng các test case liên quan đến cache nên được tách khỏi module pip_install. Những góp ý này đã được tác giả tiếp thu và điều chỉnh trong quá trình phát triển.

Ý nghĩa với người dùng Việt Nam

Đối với cộng đồng developer Python tại Việt Nam — nơi mà các dự án thường có nhiều dependency trùng lặp thông qua các framework như Django, FastAPI hay các thư viện data science — tính năng này giúp giảm dung lượng ổ đĩa đáng kể và tăng tốc độ cài đặt package, đặc biệt hữu ích khi làm việc trên máy có ổ cứng giới hạn hoặc sử dụng CI/CD với bộ nhớ cache giới hạn.

Tính năng này hiện đang trong giai đoạn preview (cờ preview), nghĩa là người dùng có thể trải nghiệm sớm nhưng cần theo dõi các thay đổi trước khi chính thức ổn định. Với tốc độ phát triển của uv, đây hứa hẹn sẽ là một bước tiến quan trọng trong việc tối ưu hóa workflow Python hiện đại.