Разработчики в последнее время кто отвечает за систему управления пакетами Волок (в дистрибутиве Gentoo Linux) объявила о выпуске стабильной версии 3.0.
В котором, главная новинка представленной новой отрасли - это работа, которая проводилась в долгосрочной перспективе по переход на Python 3 и прекращение поддержки Python 2.7 (то, что уже давно предвидели, так как эта ветка официально не поддерживалась несколько месяцев)
У нас хорошие новости! Проект Gentoo Portage недавно стабилизировал версию 3.0 менеджера пакетов.
Какие новости? Что ж, эта третья версия Portage удаляет поддержку Python 2.7, которая в течение 2020 года продолжалась в основном репозитории Gentoo проектом Gentoo Python.
Помимо прекращения поддержки 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, но задача оказалась слишком сложной, поскольку это требовало переноса большого количества кода, и в то же время было сомнительно, что результат стоит затраченных усилий.
В конце концов если вы хотите узнать об этом больше О примечании к выпуску этой стабильной ветки вы можете проверить подробности По следующей ссылке.