Fejlesztők a közelmúltban akik felelősek a csomagkezelő rendszerért fuvarozás (a Gentoo Linux disztribúción) bejelentette a 3.0 verzió stabil verziójának kiadását.
Amiben, a fő újdonság ennek az új ágnak a bemutatása az a munka, amelyet hosszú távon végeztek a áttérés a Python 3-ra és a Python 2.7 támogatásának vége (olyasmi, amit már sokáig látni lehetett, mivel ez a fiók hivatalosan több hónapig volt támogatás nélkül)
Jó híreink vannak! A Gentoo Portage projekt nemrégiben stabilizálta a csomagkezelő 3.0 verzióját.
Mi újság? Nos, a Portage ezen harmadik verziója megszünteti a Python 2.7 támogatását, amely a Gentoo Python projekt révén 2020-ig folyamatos erőfeszítéseket tett a Gentoo fő adattárában.
A Python 2.7 támogatásának megszüntetése mellett újabb jelentős változás amely kiemelkedik a Portage 3.0 új stabil ágából különféle optimalizációk beépítése volt hogy megengedték sokkal gyorsabban végezhet számításokat (50% és 60% között) függőségek meghatározásával jár.
Érdekes módon néhány fejlesztő azt javasolta, hogy a függőségi felbontás kódját írja át a C / C ++ vagy a Go fájlba a munka felgyorsítása érdekében, de a meglévő problémát nagy erőfeszítésekkel sikerült megoldaniuk.
És ez az a meglévő kód profilja legtöbbször azt mutatta számítás elkötelezett a use_reduce és a catpkgsplit függvények meghívására ismétlődő érvkészlettel (az a személy, aki ezt a munkát vezette, megemlíti, hogy például a catpkgsplit függvényt 1-5 milliószor hívták meg).
Az észlelt problémával említse meg, hogy a számítások felgyorsítása érdekében gyorsítótárat alkalmaztak e funkciók eredményét szótárak segítségével.
Ezenkívül a felhasználó által biztosított javítás miatt a frissítés a Portage legújabb verziójára jelentősen, 50-60% -kal felgyorsíthatja a függőségi számításokat. Szeretjük látni, hogy közösségünk részt vesz a szoftverünkben! További részletekért nézze meg ezt a Reddit bejegyzést a javítást biztosító közösségi tagtól. Maradjon egészséges és főzzön tovább a Gentoo-val!
Amellett, hogy azt is megjegyzi, hogy a lru_cache beépített funkciója optimális volt a gyorsítótár gyorsítótárazására, de a 3.2 óta csak Python verziókban volt elérhető.
A visszamenőleges kompatibilitás érdekében egy csonkot is hozzáadtak az lru_cache helyettesítéséhez, de a Python 2.7 támogatásnak a Portage 3.0-ban történő leállításáról szóló döntés jelentősen leegyszerűsítette a feladatot és lehetővé tette ennek a rétegnek a megkerülését.
Töltöttem egy ideig a Portage profilozását a cProfile és a vmprof segítségével, hogy megértsem, mely funkciók veszik el a legtöbb időt. A profilozó eredményekből generáltam néhány flamegraph-ot is, amelyek így néztek ki. Azt vettem észre, hogy néhány funkció, például
use_reduceycatpkgsplit, nagyon gyakran hívják ugyanazokkal az érvekkel (például 1-5 milliószor acatpkgsplit). Néhány kísérletet végeztem e funkciók eredményeinek gyorsítótárazásában egy diktátumban, és miután némi jó gyorsítást láttam, beküldtem egy javítást a Portage fejlesztői listájára. Valaki javasolta a beépített Python használatátlru_cachefunkció dekoratőr helyett, de ez csak a Python 3.2-es és újabb verzióiban érhető el.
Másrészt a gyorsítótár használata 220 perc 5 másodpercről 20 perc 3 másodpercre (16%) csökkentette a ThinkPad X63 "emerge -uDvpU –with-bdeps = y @world" műveletét (48%). Más rendszereken végzett tesztek legalább XNUMX% -os teljesítménynövekedést mutattak.
A változást előkészítő fejlesztő egy prototípust is megpróbált megvalósítani a függőségi felbontási kódból C ++ vagy Rust, de a feladat túl nehéznek bizonyult, mivel nagy mennyiségű kódot igényelt, és kétséges volt, hogy az eredmény megéri-e a fáradságot.
Végül ha többet szeretne tudni róla Ennek a stabil ágnak a kiadási megjegyzéséről ellenőrizheti a részleteket A következő linken.