Các nhà phát triển gần đây người phụ trách hệ thống quản lý gói Portage (trên bản phân phối Gentoo Linux) thông báo về việc phát hành phiên bản ổn định của phiên bản 3.0.
Trong đó, tính mới chính của chi nhánh mới này được trình bày, là công việc được thực hiện trong thời gian dài trên chuyển đổi sang Python 3 và kết thúc hỗ trợ cho Python 2.7 (điều mà người ta đã thấy nó đến từ rất lâu rồi, vì chi nhánh này đã chính thức không được hỗ trợ trong vài tháng)
Chúng tôi có tin tốt! Dự án Gentoo Portage gần đây đã ổn định phiên bản 3.0 của trình quản lý gói.
Có gì mới? Chà, phiên bản thứ ba này của Portage loại bỏ hỗ trợ cho Python 2.7, đây là một nỗ lực không ngừng trong kho lưu trữ Gentoo chính của dự án Gentoo Python trong suốt năm 2020.
Ngoài việc ngừng hỗ trợ cho Python 2.7, một thay đổi lớn khác nổi bật so với nhánh ổn định mới này của Portage 3.0 là sự bao gồm của các tối ưu hóa khác nhau mà họ cho phép thực hiện tính toán nhanh hơn nhiều (từ 50% đến 60%) kết hợp với việc xác định các phụ thuộc.
Điều thú vị là một số nhà phát triển đã đề xuất viết lại mã giải quyết sự phụ thuộc bằng C / C ++ hoặc Go để tăng tốc công việc của họ, nhưng họ đã cố gắng giải quyết vấn đề hiện tại với nỗ lực rất lớn.
Và đó là hồ sơ của mã hiện tại cho thấy rằng hầu hết thời gian phép tính dành riêng cho việc gọi các hàm use_reduce và catpkgsplit với một tập hợp các đối số lặp lại (người đứng đầu công trình này đề cập rằng ví dụ, hàm catpkgsplit được gọi từ 1 đến 5 triệu lần).
Với sự cố được phát hiện, hãy đề cập đến vấn đề đó để tăng tốc độ tính toán, bộ nhớ đệm đã được áp dụng kết quả của các chức năng này bằng từ điển.
Ngoài ra, do bản vá do người dùng cung cấp, việc nâng cấp lên phiên bản Portage mới nhất có thể tăng tốc độ tính toán phụ thuộc lên 50-60%. Chúng tôi thích nhìn thấy cộng đồng của chúng tôi tham gia vào phần mềm của chúng tôi! Để biết thêm chi tiết, hãy xem bài đăng Reddit này từ thành viên cộng đồng đã cung cấp bản vá. Giữ sức khỏe và tiếp tục nấu ăn với Gentoo!
bên cạnh đó nó cũng lưu ý rằng hàm tích hợp lru_cache là tối ưu cho tác vụ lưu vào bộ nhớ đệm này, nhưng nó chỉ có sẵn trong các phiên bản Python kể từ 3.2.
Để tương thích ngược, một sơ khai cũng đã được thêm vào để thay thế lru_cache, nhưng quyết định chấm dứt hỗ trợ Python 2.7 trong Portage 3.0 đã đơn giản hóa đáng kể tác vụ và có thể bỏ qua lớp này.
Tôi đã dành một chút thời gian để lập hồ sơ Portage với cProfile và vmprof để hiểu tính năng nào đang chiếm nhiều thời gian nhất. Tôi cũng đã tạo một số bản ghi ngọn lửa từ kết quả của trình biên dịch, trông giống như thế này. Điều tôi nhận thấy là một số chức năng, như
use_reduceycatpkgsplit, được gọi rất thường xuyên với các đối số giống nhau (như, 1 đến 5 triệu lần, chocatpkgsplit). Tôi đã thực hiện một số thử nghiệm để lưu vào bộ nhớ cache kết quả của các hàm này trong một bài chính tả và sau khi thấy một số tốc độ tốt, tôi đã gửi một bản vá cho danh sách nhà phát triển Portage. Ai đó đã đề xuất sử dụng Python tích hợp sẵnlru_cachethay vào đó, trình trang trí chức năng, nhưng điều đó chỉ có sẵn trong Python 3.2 trở lên.
Mặt khác, việc sử dụng bộ nhớ đệm đã làm giảm hoạt động "raise -uDvpU –with-bdeps = y @world" trên ThinkPad X220 từ 5 phút 20 giây xuống 3 phút 16 giây (63%). Các thử nghiệm trên các hệ thống khác đã cho thấy hiệu suất tăng ít nhất 48%.
Nhà phát triển chuẩn bị thay đổi cũng đã cố gắng triển khai một nguyên mẫu từ mã phân giải phụ thuộc trong C ++ hoặc Rust, nhưng nhiệm vụ hóa ra quá khó, vì nó yêu cầu một lượng lớn mã được thực hiện và đồng thời người ta nghi ngờ liệu kết quả có xứng đáng với nỗ lực không.
Cuối cùng nếu bạn muốn biết thêm về nó Về ghi chú phát hành của nhánh ổn định này, bạn có thể kiểm tra chi tiết Trong liên kết sau đây.