Utvecklare nyligen som ansvarar för pakethanteringssystemet Portage (på Gentoo Linux-distributionen) tillkännagav lanseringen av den stabila versionen av version 3.0.
I vilken, den viktigaste nyheten av denna nya gren presenteras, är det arbete som utfördes på lång sikt på övergång till Python 3 och slut på stöd för Python 2.7 (något som redan sågs komma under lång tid, eftersom denna filial officiellt var utan stöd i flera månader)
Vi har goda nyheter! Gentoo Portage-projektet har nyligen stabiliserat version 3.0 av pakethanteraren.
Vad är nytt? Nåväl, den här tredje versionen av Portage tar bort stöd för Python 2.7, vilket har varit ett pågående arbete i Gentoo-huvudförvaret av Gentoo Python-projektet under hela 2020.
Förutom avvecklingen av stödet för Python 2.7, en annan stor förändring som sticker ut från denna nya stabila gren av Portage 3.0 var införandet av olika optimeringar som de tillät göra beräkningar mycket snabbare (mellan 50% och 60%) associerad med att bestämma beroenden.
Intressant nog föreslog vissa utvecklare att skriva om kod för beroendeupplösning i C / C ++ eller Go för att påskynda sitt arbete, men de lyckades lösa det befintliga problemet med stor ansträngning.
Och det profilen för den befintliga koden visade att för det mesta beräkning är tillägnad att anropa funktionerna use_reduce och catpkgsplit med en upprepad uppsättning argument (personen som ledde detta arbete nämner att catpkgsplit-funktionen till exempel kallades 1 till 5 miljoner gånger).
Med det upptäckta problemet, nämn att för att påskynda beräkningarna, cachning applicerades resultatet av dessa funktioner med hjälp av ordböcker.
På grund av en patch från användaren kan uppdatering till den senaste versionen av Portage påskynda beroendeberäkningarna med 50-60%. Vi älskar att se vårt samhälle delta i vår programvara! För mer information, kolla in detta Reddit-inlägg från den communitymedlem som tillhandahåller korrigeringen. Håll dig frisk och fortsätt laga med Gentoo!
Förutom det den noterar också att den inbyggda lru_cache-funktionen var optimal för denna cachinguppgift, men den var endast tillgänglig i Python-versioner sedan 3.2.
För bakåtkompatibilitet tillsattes också en stub för att ersätta lru_cache, men beslutet att avsluta Python 2.7-stöd i Portage 3.0 förenklar uppgiften kraftigt och gjorde det möjligt att kringgå detta lager.
Jag tillbringade lite tid på att profilera Portage med cProfile och vmprof för att förstå vilka funktioner som tog mest tid. Jag genererade också några flamegrafer från profileringsresultaten, som såg ut så här. Vad jag märkte var att vissa funktioner, som
use_reduceycatpkgsplit, kallas mycket ofta med samma argument (som 1 till 5 miljoner gånger, förcatpkgsplit). Jag gjorde några experiment för att cacha resultaten av dessa funktioner i en diktat, och efter att ha sett några bra speedups skickade jag en patch till Portage-utvecklarlistan. Någon föreslog att använda inbyggd Pythonlru_cachefunktionsdekoratör istället, men det finns bara i Python 3.2 och högre.
Å andra sidan har användningen av cachen minskat operationen "emerge -uDvpU –with-bdeps = y @world" på ThinkPad X220 från 5 minuter 20 sekunder till 3 minuter 16 sekunder (63%). Tester på andra system har visat en prestandavinst på minst 48%.
Utvecklaren som förberedde förändringen försökte också implementera en prototyp från beroendekoden i C ++ eller Rust, men uppgiften visade sig vara för svår, eftersom det krävdes att en stor mängd kod skulle transporteras och samtidigt var det tveksamt om resultatet var värt ansträngningen.
Slutligen om du vill veta mer om det Om utgåvan av denna stabila filial kan du kontrollera detaljerna I följande länk.