Po pierwsze, kilka wyjaśnień: Python jest językiem. Istnieje kilka różnych interpretatorów, które mogą wykonywać kod napisany w języku Python. Implementacja referencyjna (CPython) jest zwykle tym, do której się odwołuje się, gdy ktoś mówi o „Python” tak, jakby to była implementacja, ale ważne jest, aby być precyzyjnym, gdy mówi się o charakterystyce wydajności, ponieważ mogą się one bardzo różnić między implementacjami.
Jak i gdzie przyjmujemy SRP bez uszczerbku dla wydajności w Pythonie, ponieważ jego implementacja bezpośrednio na niego wpływa?
Przypadek 1.)
Jeśli masz czysty kod Python (<= język Python w wersji 3.5, 3.6 ma „obsługę wersji beta”), który opiera się tylko na czystych modułach Python, możesz objąć SRP wszędzie i użyć PyPy, aby go uruchomić. PyPy ( https://morepypy.blogspot.com/2019/03/pypy-v71-released-now-uses-utf-8.html ) to interpreter języka Python, który ma kompilator Just in Time (JIT) i może usunąć funkcję wywołać narzut, o ile ma wystarczająco dużo czasu na „rozgrzanie” przez śledzenie wykonanego kodu (kilka sekund IIRC). **
Jeśli jesteś ograniczony do używania interpretera CPython, możesz wyodrębnić powolne funkcje do rozszerzeń napisanych w C, które zostaną wstępnie skompilowane i nie będą obciążone żadnymi narzutami interpretera. Nadal możesz używać SRP wszędzie, ale twój kod zostanie podzielony między Python i C. To, czy jest to lepsze, czy gorsze pod względem konserwacji, niż selektywne porzucanie SRP, ale trzymanie się tylko kodu Python zależy od twojego zespołu, ale jeśli masz sekcje krytyczne pod względem wydajności kodu, będzie on niewątpliwie szybszy niż nawet najbardziej zoptymalizowany czysty kod Pythona interpretowany przez CPython. Wiele najszybszych bibliotek matematycznych Pythona korzysta z tej metody (numpy i scipy IIRC). Co jest miłym przejściem do przypadku 2 ...
Przypadek 2.)
Jeśli masz kod Pythona, który używa rozszerzeń C (lub polega na bibliotekach, które używają rozszerzeń C), PyPy może, ale nie musi być przydatny, w zależności od tego, jak zostały napisane. Szczegółowe informacje można znaleźć na stronie http://doc.pypy.org/en/latest/extending.html , ale podsumowanie jest takie, że CFFI ma minimalny narzut, podczas gdy CTypes jest wolniejszy (użycie go z PyPy może być nawet wolniejsze niż CPython)
Cython ( https://cython.org/ ) to kolejna opcja, z którą nie mam tyle doświadczenia. Wspominam o tym w celu uzupełnienia, aby moja odpowiedź była „samodzielna”, ale nie wymagała żadnej wiedzy specjalistycznej. Po moim ograniczonym użyciu czułem, że musiałem ciężko pracować, aby uzyskać te same ulepszenia prędkości, które mogłem uzyskać „za darmo” z PyPy, a jeśli potrzebowałem czegoś lepszego niż PyPy, równie łatwo było napisać własne rozszerzenie C ( co ma tę zaletę, że jeśli ponownie użyję kodu w innym miejscu lub wyodrębnię jego część do biblioteki, cały mój kod może nadal działać pod dowolnym interpreterem Pythona i nie musi być uruchamiany przez Cython).
Boję się, że będę „zamknięty” w Cython, podczas gdy każdy kod napisany dla PyPy może również działać w CPython.
** Kilka dodatkowych uwag na temat PyPy w produkcji
Bądź bardzo ostrożny przy dokonywaniu wyborów, które mają praktyczny efekt „zablokowania cię” w PyPy w dużej bazie kodu. Ponieważ niektóre (bardzo popularne i przydatne) biblioteki stron trzecich nie grają dobrze z wyżej wymienionych powodów, może to powodować bardzo trudne decyzje później, jeśli zdasz sobie sprawę, że potrzebujesz jednej z tych bibliotek. Moje doświadczenie polega przede wszystkim na korzystaniu z PyPy w celu przyspieszenia niektórych (ale nie wszystkich) mikrousług, które są wrażliwe na wydajność w środowisku firmowym, gdzie dodaje ono znikomą złożoność do naszego środowiska produkcyjnego (mamy już wdrożonych wiele języków, niektóre z różnymi głównymi wersjami, takimi jak 2.7 vs 3.5 działa mimo to).
Odkryłem, że używanie zarówno PyPy, jak i CPython regularnie zmuszało mnie do pisania kodu, który opiera się tylko na gwarancjach wynikających z samej specyfikacji języka, a nie na szczegółach implementacji, które mogą ulec zmianie w dowolnym momencie. Może ci się wydawać, że myślenie o takich szczegółach stanowi dodatkowe obciążenie, ale uznałem je za cenne w moim rozwoju zawodowym i myślę, że jest „zdrowe” dla całego ekosystemu Python.