Izstrādātāji nesen kas atbild par paku pārvaldības sistēmu Portage (Gentoo Linux izplatīšanā) paziņoja par 3.0 versijas stabilās versijas izlaišanu.
Kurā, galvenais jaunums šīs jaunās filiāles prezentācija ir darbs, kas ilgtermiņā tika veikts pāreja uz Python 3 un atbalsta pārtraukšana Python 2.7 (kaut kas jau sen bija redzams nākam, jo šī filiāle vairākus mēnešus bija oficiāli bez atbalsta)
Mums ir labas ziņas! Gentoo Portage projekts nesen ir stabilizējis pakotņu pārvaldnieka 3.0 versiju.
Kas jauns? Nu, šī trešā Portage versija noņem atbalstu Python 2.7, kas ir bijis nepārtraukts darbs Gentoo Python projekta galvenajā Gentoo repozitorijā visu 2020. gadu.
Papildus atbalsta pārtraukšanai Python 2.7, vēl viena liela pārmaiņa kas izceļas no šīs jaunās stabilās Portage 3.0 filiāles bija dažādu optimizāciju iekļaušana ka viņi ļāva veikt aprēķinus daudz ātrāk (no 50% līdz 60%) kas saistīti ar atkarību noteikšanu.
Interesanti, ka daži izstrādātāji ieteica pārrakstīt atkarības izšķirtspējas kodu C / C ++ vai Go, lai paātrinātu viņu darbu, taču viņiem ar lielām pūlēm izdevās atrisināt esošo problēmu.
Un tas esošā koda profils to lielākoties parādīja aprēķins ir veltīts funkciju_saukšana un samazināšana un catpkgsplit izsaukšanai ar atkārtotu argumentu kopumu (persona, kas vadīja šo darbu, piemin, ka, piemēram, catpkgsplit funkcija tika izsaukta 1 līdz 5 miljonus reižu).
Atrodot problēmu, pieminiet, ka, lai paātrinātu aprēķinus, tika izmantota kešatmiņa no šo funkciju rezultāta, izmantojot vārdnīcas.
Arī lietotāja piedāvāta plākstera dēļ atjaunināšana uz jaunāko Portage versiju var ievērojami paātrināt atkarības aprēķinus par 50-60%. Mums patīk redzēt, kā mūsu kopiena piedalās mūsu programmatūrā! Lai iegūtu sīkāku informāciju, skatiet šo Reddit ziņu no kopienas locekļa, kurš nodrošināja plāksteri. Esiet vesels un turpiniet gatavot ēdienu kopā ar Gentoo!
Bez tam tā arī atzīmē, ka iebūvētā funkcija lru_cache bija optimāla šim kešatmiņas uzdevumam, taču tas bija pieejams tikai Python versijās kopš 3.2.
Lai nodrošinātu savietojamību ar atpakaļejošu datumu, tika pievienots arī spraudnis, lai aizstātu lru_cache, taču lēmums pārtraukt Python 2.7 atbalstu Portage 3.0 ievērojami vienkāršoja uzdevumu un ļāva apiet šo slāni.
Es pavadīju kādu laiku, veidojot Portage profilēšanu ar cProfile un vmprof, lai saprastu, kuras funkcijas izmanto visilgāk. Es arī ģenerēju dažus flamegrāfus no profilētāja rezultātiem, kas izskatījās šādi. Es pamanīju, ka dažas funkcijas, piemēram,
use_reduceycatpkgsplit, tiek izsaukti ļoti bieži ar tiem pašiem argumentiem (piemēram, 1 līdz 5 miljonus reižu, parcatpkgsplit). Es veicu dažus eksperimentus, lai diktētā kešatmiņā saglabātu šo funkciju rezultātus, un, redzot dažus labus paātrinājumus, es iesniedzu plāksteri Portage izstrādātāju sarakstā. Kāds ieteica izmantot iebūvēto Pythonlru_cachetā vietā, taču tas ir pieejams tikai Python 3.2 un jaunākās versijās.
No otras puses, kešatmiņas izmantošana samazināja ThinkPad X220 darbību "emerge -uDvpU –with-bdeps = y @world" no 5 minūtēm 20 sekundēm līdz 3 minūtēm 16 sekundēm (63%). Pārbaudot citas sistēmas, veiktspējas pieaugums ir vismaz 48%.
Izstrādātājs, kurš sagatavoja izmaiņas, arī mēģināja ieviest prototipu no atkarības izšķiršanas koda C ++ vai Rust, bet uzdevums izrādījās pārāk grūts, jo tas prasīja liela apjoma koda pārnešanu un vienlaikus bija šaubas, vai rezultāts ir vērts pūļu.
Beidzot ja vēlaties uzzināt vairāk par to Par šīs stabilās filiāles izlaišanas piezīmi varat pārbaudīt informāciju Šajā saitē.