Cel mai bun răspuns
Python este interpretat. Deși convertește sursa care poate fi citită de om în bytecode, pe care o stochează în fișierul .pyc, iar fișierul .pyc este portabil, fișierul .pyc este totuși interpretat. De exemplu, unii interpreți Python cache obiecte singleton pentru numere întregi utilizate în mod obișnuit -100 până la 100. Unii nu. Cum contează?
Un sistem poate interpreta în mod legal operațiunea is, care compară Object.id () cu adevărat sau cu fals.
x = 20
x is 20 # Both True and False are valid results.
Demonstrație:
$ 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
>>>
Conversia sursa python până la bytecode necesită timp, în mod rezonabil este mai rapid pentru python să citească fișierul .pyc decât să citească sursa și să reconstruiască .pyc.
A fost un timp și nu am ținut pasul cu importarea modulelor, când python ar căuta \_\_init\_\_.py într-un director pentru a încărca un modul. Era înțelept să păstrezi micul fișier \_\_init\_\_.py, pentru a-l importa în mod secundar codul util care ar rezida într-un fișier .pyc.
Și optimizarea python a mers oriunde? Știam ultima dată, ceea ce a fost cu mult timp în urmă, .pyo era un .pyc cu comentarii dezbrăcate.
Răspuns
Am mai răspuns la acest lucru aici: răspunsul lui Quildreen Motta la Poate fi compilat un limbaj la nivel înalt, cum ar fi Python, făcându-l la fel de rapid ca C?
Dar pe scurt, oamenii nu folosesc C sau C ++ pentru că „re rapid , le folosesc pentru că au o performanță oarecum predictibilă . Un programator își poate lua apoi timpul pentru a-și optimiza manual programele și „este mult mai ușor să te gândești la performanțele rezultate din aceste optimizări.
Asta nu este atât de ușor de realizat într-un limbaj dinamic, cum ar fi Python. Cu toate acestea, PyPy îți va oferi mai repede decât … C (gcc, nu complet optimizat manual) în mai multe scenarii, nu puteți prevedea când se întâmplă aceste scenarii, deoarece depinde de mai mulți factori (ce date trec prin programul dvs., ce ramuri au fost luate, stabilitatea ramuri peste t ime, calitatea codului etc.).
Desigur, PyPy face toate optimizările în timp ce rulează programul, deci trebuie să facă o mulțime de ponderare a costurilor și unele optimizări nu se aplică pentru ca. La fel cum compilatoarele AOT ar putea petrece 3 luni analizând codul dvs. pentru a genera COD REALMENT RAPID, optimizatorii JIT ar putea petrece minute analizându-vă codul. În niciun caz, costul este probabil să dea roade, așa că nu fac asta.
Efectuarea compilatoarelor AOT pentru Python este mult mai dificilă, deoarece Python este un limbaj dinamic. Compilatoarele AOT, cum ar fi shedskin – Un compilator experimental (restricționat-Python) -to-C ++ , folosește în schimb un subset restrâns de Python pentru a-l putea analiza static. Această abordare este similară cu una luată de RPython, pe care se bazează PyPy.