11
Warum Python die Quelle zu Bytecode vor der Interpretation kompilieren?Warum kompilieren Python die Quelle zu Bytecode vor der Interpretation?
Warum nicht direkt von der Quelle interpretieren?
A
Antwort
33
Fast kein Interpreter interpretiert Code direkt, Zeile für Zeile - es ist einfach zu ineffizient. Fast alle Dolmetscher verwenden eine Zwischenrepräsentation, die leicht ausgeführt werden kann. Außerdem können kleine Optimierungen an diesem Zwischencode durchgeführt werden.
Python speichert außerdem diesen Code, der einen großen Vorteil für die nächste Ausführung dieses Codes hat: Python muss den Code nicht mehr analysieren; Das Parsen ist der langsamste Teil des Kompilierungsprozesses. Somit reduziert eine Bytecodedarstellung den Ausführungsoverhead ziemlich wesentlich.
+1
Sogar das alte MS BASIC auf meinem TRS-80 verwendete ein sehr einfaches Kodierungsschema: sobald ich eine Zeile eintippte oder editierte, wurden die BASIC Schlüsselwörter in einzelne Bytes zusammengefasst. –
+1
@DavidThornley: Viele Computer der 1980er Jahre verwendeten ein Derivat von MS-basic, das Schlüsselwörter in Token umwandelte, aber Zahlen und Variablennamen in Textform behielt und damit ihre Werte berechnen oder zur Laufzeit nachschlagen musste. Atari BASIC hat mehr verarbeitet, eine Tabelle von Variablen erstellt und deren Namen durch Indizes ersetzt. Außerdem wurden numerische Zahlen in BCD-Gleitkommazahlen umgewandelt. Nur String-Literale und Kommentare wurden als Text gespeichert. Solche Dinge hätten es Atari BASIC ermöglicht, andere zu übertreffen, außer dass die Nummer jeder Zeile als Binärdatei gespeichert wurde, aber GOTO-Ziele ... – supercat
+1
... als BCD Gleitkomma gespeichert wurden, so dass jede GOTO eine BCD-zu-Binär Konvertierung benötigte . Dennoch ist es interessant, dass der Autor von Atari BASIC das Programm in eine geparste Darstellung umwandelte, anstatt einfach Schlüsselwörter durch Token zu ersetzen. – supercat
7
Weil die Interpretation von Bytecode direkt schneller ist. Es vermeidet die Notwendigkeit, für eine Sache zu lexing.
8
Da können Sie zu einem einmal kompilieren und daraus viele Male interpretieren.
Wenn Sie also ein Skript mehrmals ausführen, haben Sie nur den Aufwand, den Quellcode einmal zu analysieren.
6
Den Quellcode immer wieder neu zu lexen und zu analysieren, anstatt es nur einmal zu tun (am häufigsten auf der ersten import), wäre offensichtlich eine alberne und sinnlose Verschwendung von Aufwand.
+0
Wenn Sie nur eine ".py" -Datei ausführen, führt dies dazu, dass Sie den Quellcode immer wieder neu lexen und analysieren, richtig? Wenn die Datei groß ist, kann dies einen erheblichen Mehraufwand bedeuten. Ich bin mir nicht sicher, warum der Import eine spezielle Behandlung erhält. Ich würde wirklich jede Hilfe beim Verständnis schätzen. – batbrat
-1
Ich bezweifle sehr, dass der Grund Leistung ist, obwohl es ein schöner Nebeneffekt ist. Ich würde sagen, dass es nur natürlich ist, zu glauben, dass eine VM, die auf einer höheren Assemblersprache aufgebaut ist, praktischer wäre, als Text in einer Quellcodekette zu finden und zu ersetzen.
Edit:
Okay, klar, die jemals eine -1 Abstimmung über meinen Beitrag setzen, ohne einen vernünftigen Kommentar zu verlassen sehr wenig über virtuelle Maschinen zu erklären weiß (Laufzeitumgebungen).
+1
Ich habe nicht -1, aber ich werde ehrlich sein, dass ich Ihren Punkt, insbesondere diesen Teil davon nicht verstanden habe: "wäre praktischer als zu finden und zu ersetzen Text in einigen Quelltext-String" –
+0
Sehen Sie sich das Video an channel 9, oder schreiben Sie Ihre eigene VM, zwei würden Ihnen wahrscheinlich den gesamten Prozess im Detail erklären. Mit diesem Zitat habe ich gemeint, dass es manchmal einfacher ist, Optimierungen auf einer höheren Abstraktionsebene als Assembly durchzuführen. Wenn Sie dies normalerweise tun, arbeiten Sie mit einem AST (abstrakter Syntaxbaum). Wenn Sie keinen haben, können Sie immer noch dieselben Optimierungen durchführen, aber sie müssen den Quellcode verschieben, dh suchen und ersetzen, und das ist wirklich unpraktisch tendieren aus diesem Grund dazu, mit einer anderen Zwischendarstellung zu gehen (siehe Dreiadresscode). –
+0
Der Byte-Code ist nur eine effizientere kompakte und praktische Darstellung des AST. –
2
Obwohl es eine kleine Effizienz Aspekt ist (Sie können die Bytecode auf der Festplatte oder im Speicher ablegen können), seine meist Engineering: es erlaubt Ihnen, von der Interpretation trennen Parsen. Parser können oft fiese Kreaturen sein, voller Edge-Fälle und müssen sich an esoterische Regeln halten, wie zum Beispiel die richtige Menge an Lookahead und die Lösung von Shift-Reduction-Problemen. Im Gegensatz dazu ist das Dolmetschen wirklich einfach: Es ist nur eine große switch-Anweisung, die den Opcode des Bytecodes verwendet.
Klingt wie Hausaufgaben für mich. –