Najlepsza odpowiedź
Python jest interpretowany. Mimo że konwertuje czytelne dla człowieka źródło na kod bajtowy, który przechowuje w pliku .pyc, a plik .pyc jest przenośny, plik .pyc jest mimo wszystko interpretowany. Na przykład niektóre interpretery języka Python buforują pojedyncze obiekty dla powszechnie używanych liczb całkowitych od -100 do 100. Niektóre nie. Jakie to ma znaczenie?
System może zgodnie z prawem zinterpretować operację is, która porównuje Object.id () jako True lub False.
x = 20
x is 20 # Both True and False are valid results.
Demonstracja:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:45:48)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 30
>>> x is 30
True
>>> x = 23442.2
>>> x is 23442.2
False
>>>
Konwersja źródło pythona do kodu bajtowego wymaga czasu, rozsądnie jest dla Pythona szybsze odczytanie pliku .pyc niż odczytanie źródła i rekonstrukcję .pyc.
Był taki czas, a ja nie nadążałem importowanie modułów, gdy Python szukałby \_\_init\_\_.py w katalogu, aby załadować moduł. Rozsądnie było zachować ten plik \_\_init\_\_.py jako mały, głównie po to, aby po prostu wtórnie importował przydatny kod, który znajdowałby się w pliku .pyc.
A czy optymalizacja w Pythonie poszła gdziekolwiek? Ostatnio wiedziałem, co było dość dawno temu, .pyo to .pyc z usuniętymi komentarzami.
Odpowiedź
Odpowiedziałem na to wcześniej tutaj: odpowiedź Quildreen Motta na Czy można skompilować język wysokiego poziomu, taki jak Python, czyniąc go tak szybkim jak C?
Ale krótko mówiąc, ludzie nie używają C ani C ++, ponieważ „re fast , używają ich, ponieważ mają nieco przewidywalną wydajność . Programista może wtedy poświęcić czas na ręczną optymalizację swoich programów i o wiele łatwiej jest wnioskować o wynikowej wydajności z tych optymalizacji.
Nie jest to takie łatwe w dynamicznym języku, takim jak Python. Niemniej PyPy zapewni C (gcc, nie do końca zoptymalizowana ręcznie) w kilku scenariuszach, po prostu nie można przewidzieć, kiedy te scenariusze wystąpią, ponieważ zależy to od kilku czynników (które dane przechodzą przez program, które gałęzie zostały pobrane, stabilność gałęzie ponad t ime, aktualność kodu itp.).
Oczywiście PyPy wykonuje wszystkie optymalizacje podczas działania programu, więc musi wykonywać dużo ważenia kosztów, a niektóre optymalizacje nie są stosowane z tego powodu. Podobnie jak kompilatory AOT mogą spędzić 3 miesiące na analizowaniu kodu w celu wygenerowania NAPRAWDĘ SZYBKIEGO KODU, optymalizatory JIT mogą poświęcić minuty na analizę kodu. W żadnym przypadku koszt prawdopodobnie się opłaci, więc nie robią tego.
Tworzenie kompilatorów AOT dla Pythona jest znacznie trudniejsze, ponieważ Python jest językiem dynamicznym. Kompilatory AOT, takie jak shedskin – Eksperymentalny (ograniczony-Python) -to-C ++ kompilator , zamiast tego użyj ograniczonego podzbioru Pythona, aby móc go statycznie analizować. To podejście jest podobne do jeden zrobiony przez RPython, na którym oparty jest PyPy.