最近の開発者 パッケージ管理システムの担当者 ポーテージ （Gentoo Linuxディストリビューション上） バージョン3.0の安定バージョンのリリースを発表しました。
その中で、 主な目新しさ 提示されたこの新しいブランチの、長期的に実行された作業です Python3への移行とPython2.7のサポートの終了 （このブランチは公式に数ヶ月間サポートされていなかったので、すでに長い間来ているのが見られました）
良いニュースがあります！ GentooのPortageプロジェクトは最近、パッケージマネージャーのバージョン3.0を安定させました。
新着情報？ さて、Portageのこの2.7番目のバージョンは、Python 2020のサポートを削除します。これは、XNUMX年を通してGentooPythonプロジェクトによってメインのGentooリポジトリで継続的に行われている取り組みです。
Python 2.7のサポートの終了に加えて、 別の大きな変化 これは、Portage3.0のこの新しい安定したブランチから際立っています。 さまざまな最適化が含まれていました 彼らが許可したこと 計算をはるかに高速にします（50％から60％の間） 依存関係の決定に関連付けられています。
興味深いことに、一部の開発者は、C / C ++またはGoで依存関係解決コードを書き直して作業をスピードアップすることを提案しましたが、彼らは多大な努力を払って既存の問題を解決することができました。
そして、それ 既存のコードプロファイルは、ほとんどの場合、 計算 use_reduce関数とcatpkgsplit関数の呼び出し専用です 一連の引数が繰り返されます（この作業を主導した人は、たとえば、catpkgsplit関数が1万から5万回呼び出されたと述べています）。
問題が検出されたら、計算を高速化するために、 キャッシュが適用されました 辞書によるこれらの機能の結果の。
また、ユーザー提供のパッチにより、Portageの最新バージョンに更新すると、依存関係の計算が50〜60％大幅に高速化されます。 私たちのコミュニティが私たちのソフトウェアに参加するのを見るのが大好きです！ 詳細については、パッチを提供したコミュニティメンバーからのこのRedditの投稿を確認してください。 健康を維持し、Gentooで料理を続けましょう！
それに加えて また、lru_cache組み込み関数が最適であったことにも注意してください このキャッシュタスクでは、3.2以降のPythonバージョンでのみ使用可能でした。
下位互換性のために、lru_cacheを置き換えるためにスタブも追加されましたが、Portage2.7でPython3.0のサポートを終了するという決定により、タスクが大幅に簡素化され、このレイヤーをバイパスできるようになりました。
私は、cProfileとvmprofを使用してPortageのプロファイリングに時間を費やし、どの機能が最も時間を費やしているかを理解しました。 また、プロファイラーの結果から、次のようなフレームグラフを生成しました。 私が気付いたのは、
use_reduceycatpkgsplitは、同じ引数で非常に頻繁に呼び出されます（たとえば、1万回から5万回catpkgsplit）。 これらの関数の結果をディクテーションにキャッシュするためにいくつかの実験を行い、いくつかの優れたスピードアップを確認した後、Portage開発者リストにパッチを送信しました。 誰かが組み込みのPythonを使用することを提案しましたlru_cache代わりに関数デコレータですが、これはPython3.2以降でのみ使用できます。
一方、キャッシュの使用により、ThinkPad X220での操作「emerge-uDvpU–with-bdeps = y @world」が5分20秒から3分16秒（63％）に短縮されました。 他のシステムでのテストでは、少なくとも48％のパフォーマンスの向上が示されています。
変更を準備した開発者もプロトタイプを実装しようとしました 依存関係解決コードから C ++またはRustでは、 しかし、その作業は難しすぎることが判明しました。 大量のコードを移植する必要があり、同時にその結果が努力に値するかどうかは疑わしかったためです。
最後に あなたがそれについてもっと知りたいなら この安定版ブランチのリリースノートについては、詳細を確認できます 次のリンクで。