Програмисти наскоро които отговарят за системата за управление на пакети пренос (за дистрибуцията на Gentoo Linux) обяви пускането на стабилната версия на версия 3.0.
В който, основната новост от този нов представен клон е работата, извършена в дългосрочен план върху преход към Python 3 и край на поддръжката за Python 2.7 (нещо, което вече беше видяно да идва дълго време, тъй като този клон беше официално без поддръжка в продължение на няколко месеца)
Имаме добри новини! Проектът Gentoo Portage наскоро стабилизира версия 3.0 на мениджъра на пакети.
Какво ново? Е, тази трета версия на Portage премахва поддръжката за Python 2.7, което е непрекъснато усилие в основното хранилище на Gentoo от проекта Gentoo Python през 2020 г.
В допълнение към прекратяването на поддръжката за Python 2.7, друга голяма промяна което се откроява от този нов стабилен клон на Portage 3.0 беше включването на различни оптимизации че те позволиха прави изчисления много по-бързо (между 50% и 60%) свързани с определяне на зависимости.
Интересното е, че някои разработчици предлагат да пренапишат кода за разрешаване на зависимости в C / C ++ или Go, за да ускорят работата си, но успяха да решат съществуващия проблем с големи усилия.
И съществуващия кодов профил показва, че през повечето време изчисление е посветена на извикването на функциите use_reduce и catpkgsplit с повтарящ се набор от аргументи (човекът, който е ръководил тази работа, споменава, че например функцията catpkgsplit е била извикана от 1 до 5 милиона пъти).
С открития проблем споменете, че за да ускорите изчисленията, бе приложено кеширане на резултата от тези функции с помощта на речници.
Освен това, поради предоставената от потребителя корекция, надстройването до последната версия на Portage може значително да ускори изчисленията на зависимостта с 50-60%. Обичаме да виждаме как нашата общност участва в нашия софтуер! За повече подробности вижте тази публикация в Reddit от член на общността, предоставил кръпката. Бъдете здрави и продължете да готвите с Gentoo!
Освен, че той също така отбелязва, че функцията за вграждане lru_cache е оптимална за тази задача на кеширане, но е налична само във версиите на Python от 3.2.
За обратна съвместимост също беше добавен мъниче, което замени lru_cache, но решението за прекратяване на поддръжката на Python 2.7 в Portage 3.0 значително опрости задачата и направи възможно заобикалянето на този слой.
Прекарах известно време в профилиране на Portage с cProfile и vmprof, за да разбера кои функции отнемат най-много време. Също така генерирах някои флеймографии от резултатите на профилиращия профил, които изглеждаха така. Това, което забелязах, беше, че някои функции, като
use_reduceycatpkgsplit, се извикват много често с едни и същи аргументи (като 1 до 5 милиона пъти, заcatpkgsplit). Направих няколко експеримента, за да кеширам резултатите от тези функции в диктовка и след като видях някои добри ускорения, изпратих кръпка в списъка за разработчици на Portage. Някой предложи да се използва вграден Pythonlru_cacheвместо това е декоратор на функции, но това се предлага само в Python 3.2 и по-нови версии.
От друга страна, използването на кеша е намалило операцията "emerge -uDvpU –with-bdeps = y @world" на ThinkPad X220 от 5 минути 20 секунди на 3 минути 16 секунди (63%). Тестовете на други системи показват увеличение на производителността от поне 48%.
Разработчикът, подготвил промяната, също се опита да внедри прототип от кода за разрешаване на зависимости в C ++ или Rust, но задачата се оказа твърде трудна, тъй като изискваше да се носи голямо количество код и в същото време беше съмнително дали резултатът си заслужава усилията.
Накрая ако искате да научите повече за това За бележката за изданието на този стабилен клон можете да проверите подробностите В следващия линк.