Розробники нещодавно які відповідають за систему управління пакетами Перенос (на дистрибутиві 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, але завдання виявилося занадто складним, оскільки це вимагало перенесення великої кількості коду, і в той же час було сумнівно, чи вартий результат того, що потрібно.
В кінці кінців якщо ви хочете дізнатися більше про це Щодо примітки до випуску цієї стабільної гілки, ви можете перевірити деталі У наступному посиланні.