Deweloperzy ostatnio którzy są odpowiedzialni za system zarządzania pakietami Przewóz (w dystrybucji Gentoo Linux) ogłosił wydanie stabilnej wersji 3.0.
W którym, główna nowość tej nowej gałęzi przedstawiono prace, które zostały przeprowadzone w perspektywie długoterminowej na przejście na Python 3 i zakończenie wsparcia dla Pythona 2.7 (coś, co widać było już od dłuższego czasu, ponieważ ten oddział był oficjalnie bez wsparcia przez kilka miesięcy)
Mamy dobrą wiadomość! Projekt Gentoo Portage niedawno ustabilizował wersję 3.0 menedżera pakietów.
Co nowego? Cóż, ta trzecia wersja Portage usuwa obsługę języka Python 2.7, o który projekt Gentoo Python nieustannie pracował w głównym repozytorium Gentoo przez cały rok 2020.
Oprócz zaprzestania obsługi Pythona 2.7, kolejna poważna zmiana która wyróżnia się na tle nowej stabilnej gałęzi Portage 3.0 było włączenie różnych optymalizacji że pozwolili wykonywać obliczenia znacznie szybciej (od 50% do 60%) związane z określaniem zależności.
Co ciekawe, niektórzy programiści sugerowali przepisanie kodu rozwiązywania zależności w C / C ++ lub Go, aby przyspieszyć swoją pracę, ale udało im się rozwiązać istniejący problem dużym wysiłkiem.
I profil istniejącego kodu pokazywał to przez większość czasu obliczenie jest przeznaczony do wywoływania funkcji use_reduce i catpkgsplit z powtarzającym się zestawem argumentów (osoba, która prowadziła tę pracę, wspomina, że na przykład funkcja catpkgsplit była wywoływana od 1 do 5 milionów razy).
Po wykryciu problemu wspomnij, że aby przyspieszyć obliczenia, zastosowano buforowanie wyniku tych funkcji za pomocą słowników.
Ponadto, dzięki poprawce dostarczonej przez użytkownika, aktualizacja Portage do najnowszej wersji może znacznie przyspieszyć obliczenia zależności o 50-60%. Cieszymy się, że nasza społeczność uczestniczy w naszym oprogramowaniu! Aby uzyskać więcej informacji, zapoznaj się z tym postem na Reddicie od członka społeczności, który dostarczył łatkę. Dbaj o zdrowie i gotuj dalej z Gentoo!
poza tym zauważa również, że wbudowana funkcja lru_cache była optymalna do tego zadania buforowania, ale było dostępne tylko w wersjach Pythona od 3.2.
Aby zapewnić kompatybilność wsteczną, dodano również kod zastępujący lru_cache, ale decyzja o zakończeniu obsługi Pythona 2.7 w Portage 3.0 znacznie uprościła zadanie i umożliwiła ominięcie tej warstwy.
Spędziłem trochę czasu na profilowaniu Portage za pomocą cProfile i vmprof, aby zrozumieć, które funkcje zajmują najwięcej czasu. Wygenerowałem również kilka flamegrafów z wyników profilera, które wyglądały tak. Zauważyłem, że niektóre funkcje, takie jak
use_reduceycatpkgsplit, są wywoływane bardzo często z tymi samymi argumentami (np. od 1 do 5 milionów razy forcatpkgsplit). Przeprowadziłem kilka eksperymentów, aby zapisać wyniki tych funkcji w dyktandzie, a po obejrzeniu kilku dobrych przyspieszeń przesłałem łatkę na listę deweloperów Portage. Ktoś zasugerował użycie wbudowanego Pythonalru_cachezamiast tego dekorator funkcji, ale jest dostępny tylko w Pythonie 3.2 i nowszych.
Z drugiej strony użycie pamięci podręcznej skróciło operację „emerge -uDvpU –with-bdeps = y @world” na ThinkPadzie X220 z 5 minut 20 sekund do 3 minut 16 sekund (63%). Testy na innych systemach wykazały wzrost wydajności o co najmniej 48%.
Deweloper, który przygotował zmianę, próbował również zaimplementować prototyp z kodu rozwiązywania zależności w C ++ lub Rust, ale zadanie okazało się zbyt trudne, ponieważ wymagało to przeniesienia dużej ilości kodu i jednocześnie było wątpliwe, czy wynik był wart wysiłku.
W końcu jeśli chcesz dowiedzieć się więcej na ten temat Jeśli chodzi o informację o wydaniu tej stabilnej gałęzi, możesz sprawdzić szczegóły W poniższym linku.