Bedste svar
python fortolkes. Selvom den konverterer den menneskelige læsbare kilde til bytecode, som den gemmer i .pyc-filen, og .pyc-filen er bærbar, fortolkes .pyc-filen ikke desto mindre. For eksempel cache nogle pythontolke cache singleton-objekter til almindeligt anvendte heltal -100 til 100. Nogle gør det ikke. Hvordan betyder det noget?
Et system kan lovligt fortolke is-operationen, der sammenligner Object.id () som True eller som False.
x = 20
x is 20 # Both True and False are valid results.
Demonstration:
$ 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
>>>
Konvertering af python-kilde til bytecode tager tid, med rimelighed er det hurtigere for python at læse .pyc-filen end at læse kilden og rekonstruere .pyc.
Der var en tid, og jeg har ikke fulgt med importerer moduler, når python ville se efter \_\_init\_\_.py i en mappe for at indlæse et modul. Det var klogt at holde den \_\_init\_\_.py-fil lille for for det meste bare at have den sekundært til at importere den nyttige kode, der ville være i en .pyc-fil.
Og gik pythonoptimering overalt? Sidst jeg vidste, hvilket var for et stykke tid siden, var .pyo en .pyc med kommentarer fjernet.
Svar
Jeg har svaret dette før her: Quildreen Mottas svar på Kan et sprog på højt niveau som Python kompileres og derved gøre det så hurtigt som C?
Men kort sagt bruger folk ikke C eller C ++, fordi de “re hurtigt , de bruger dem, fordi de har en noget forudsigelig ydeevne . En programmør kan derefter tage sig tid til at håndoptimere deres programmer og det er meget lettere at begrunde den resulterende ydeevne fra disse optimeringer.
Det er ikke så let at gøre på et dynamisk sprog som Python. Ikke desto mindre vil PyPy give dig hurtigere end- C (gcc, ikke helt håndoptimeret) ydeevne i flere scenarier, du kan bare ikke forudsige, hvornår disse scenarier sker, fordi det afhænger af flere faktorer (hvilke data der går gennem dit program, hvilke grene der er taget, stabiliteten af grene over t ime, hotness of the code osv.).
Selvfølgelig udfører PyPy alle optimeringer, mens det kører dit program, så det er nødvendigt at lave en masse omkostningsvægtning, og nogle optimeringer bliver ikke anvendt på grund af det. Ligesom AOT-kompilatorer kunne bruge 3 måneder på at analysere din kode for at generere VIRKELIG HURTIG KODE, kunne JIT-optimister bruge minutter på at analysere din kode. I begge tilfælde vil omkostningerne sandsynligvis betale sig, så de gør det ikke.
At lave AOT-compilere til Python er meget vanskeligere, fordi Python er et dynamisk sprog. AOT-compilere, såsom shedskin – En eksperimentel (begrænset-Python) -til-C ++ kompilator , brug en begrænset delmængde af Python i stedet for at være i stand til at analysere den statisk. Denne tilgang svarer til en taget af RPython, som PyPy er baseret på.