Utviklere nylig som har ansvaret for pakkehåndteringssystemet Portage (på Gentoo Linux-distribusjon) kunngjorde utgivelsen av den stabile versjonen av versjon 3.0.
Der, den viktigste nyheten av denne nye grenen som presenteres, er arbeidet som ble utført på lang sikt med overgang til Python 3 og slutt på støtte for Python 2.7 (noe som allerede ble sett komme lenge, siden denne grenen offisielt var uten støtte i flere måneder)
Vi har gode nyheter! Gentoo Portage-prosjektet har nylig stabilisert versjon 3.0 av pakkeforvalteren.
Hva er nytt? Vel, denne tredje versjonen av Portage fjerner støtte for Python 2.7, som har vært en kontinuerlig innsats i hoved Gentoo-depotet av Gentoo Python-prosjektet gjennom hele 2020.
I tillegg til avviklingen av støtten til Python 2.7, nok en stor forandring som skiller seg ut fra denne nye stabile grenen av Portage 3.0 var inkluderingen av ulike optimaliseringer som de tillot gjøre beregninger mye raskere (mellom 50% og 60%) assosiert med å bestemme avhengigheter.
Interessant, noen utviklere foreslo å skrive om avhengighetskoden i C / C ++ eller Go for å øke hastigheten på arbeidet, men de klarte å løse det eksisterende problemet med stor innsats.
Og det profilen til den eksisterende koden viste at det meste av tiden beregning er dedikert til å ringe funksjonene use_reduce og catpkgsplit med et gjentakende sett med argumenter (personen som ledet dette arbeidet nevner at catpkgsplit-funksjonen for eksempel ble kalt 1 til 5 millioner ganger).
Når problemet er oppdaget, kan du nevne at for å få raskere beregninger, caching ble brukt av resultatet av disse funksjonene ved hjelp av ordbøker.
I tillegg, på grunn av en oppdatering fra brukeren, kan oppgradering til den nyeste versjonen av Portage øke hastighetsberegningene med 50-60%. Vi elsker å se samfunnet vårt delta i programvaren vår! For mer informasjon, sjekk ut dette Reddit-innlegget fra fellesskapsmedlemmet som leverte oppdateringen. Hold deg sunn og fortsett å lage mat med Gentoo!
bortsett fra det den bemerker også at den innebygde funksjonen lru_cache var optimal for denne cachingoppgaven, men den var bare tilgjengelig i Python-versjoner siden 3.2.
For bakoverkompatibilitet ble det også lagt til en stubbe for å erstatte lru_cache, men beslutningen om å avslutte Python 2.7-støtte i Portage 3.0 forenklet oppgaven sterkt og gjorde det mulig å omgå dette laget.
Jeg brukte litt tid på å profilere Portage med cProfile og vmprof for å forstå hvilke funksjoner som tok mest tid. Jeg genererte også noen flamegrafer fra profileringsresultatene, som så slik ut. Det jeg la merke til var at noen funksjoner, som
use_reduceycatpkgsplit, kalles veldig ofte med de samme argumentene (som 1 til 5 millioner ganger, forcatpkgsplit). Jeg gjorde noen eksperimenter for å cache resultatene av disse funksjonene i en diktat, og etter å ha sett noen gode hastigheter, sendte jeg en oppdatering til listen over utviklere av Portage. Noen foreslo å bruke innebygd Pythonlru_cachefunksjon dekoratør i stedet, men det er bare tilgjengelig i Python 3.2 og nyere.
På den annen side har bruken av hurtigbufferen redusert operasjonen "emerge -uDvpU –with-bdeps = y @world" på ThinkPad X220 fra 5 minutter 20 sekunder til 3 minutter og 16 sekunder (63%). Tester på andre systemer har vist en ytelsesgevinst på minst 48%.
Utvikleren som forberedte endringen prøvde også å implementere en prototype fra avhengighetskode i C ++ eller Rust, men oppgaven viste seg å være for vanskelig, ettersom det krevde portering av en stor mengde kode, og samtidig var det tvilsomt om resultatet var verdt innsatsen.
Endelig hvis du vil vite mer om det Om utgivelsesnotatet til denne stabile grenen kan du sjekke detaljene I den følgende lenken.