Warum läuft Python-Code in einer Funktion schneller?

def main():
    for i in xrange(10**8):
        pass
main()

Dieser Code in Python läuft in (Hinweis: Das Timing erfolgt mit der Zeitfunktion in BASH unter Linux.)

real    0m1.841s
user    0m1.828s
sys     0m0.012s

Wenn die for-Schleife jedoch nicht in einer Funktion platziert ist,

for i in xrange(10**8):
    pass

dann läuft es viel länger:

real    0m4.543s
user    0m4.524s
sys     0m0.012s

Warum ist das?

Sie könnten sich fragen, warum es schneller ist, lokale Variablen als globale zu speichern. Dies ist ein CPython-Implementierungsdetail.

Denken Sie daran, dass CPython zu Bytecode kompiliert wird, den der Interpreter ausführt. Wenn eine Funktion kompiliert wird, werden die lokalen Variablen in einem Array fester Größe ( nicht a dict) gespeichert und den Indizes Variablennamen zugewiesen. Dies ist möglich, weil Sie einer Funktion keine dynamischen Variablen dynamisch hinzufügen können. Das Abrufen einer lokalen Variablen ist dann buchstäblich eine Zeigersuche in der Liste und eine Erhöhung der Anzahl der Nachzähler, PyObjectwas trivial ist.

Vergleichen Sie dies mit einem globalen Lookup ( LOAD_GLOBAL), bei dem es sich um eine echte dictSuche mit einem Hash usw. handelt. Aus diesem Grund müssen Sie im Übrigen angeben, global iob es global sein soll: Wenn Sie jemals eine Variable innerhalb eines Bereichs zuweisen, gibt der Compiler STORE_FASTs für den Zugriff aus, es sei denn, Sie weisen ihn an , dies nicht zu tun.

Übrigens sind globale Suchvorgänge immer noch ziemlich optimiert. Attributsuchen foo.barsind die wirklich langsamen!

Hier ist eine kleine Illustration zur lokalen variablen Effizienz.

Innerhalb einer Funktion lautet der Bytecode:

  2           0 SETUP_LOOP              20 (to 23)
              3 LOAD_GLOBAL              0 (xrange)
              6 LOAD_CONST               3 (100000000)
              9 CALL_FUNCTION            1
             12 GET_ITER            
        >>   13 FOR_ITER                 6 (to 22)
             16 STORE_FAST               0 (i)

  3          19 JUMP_ABSOLUTE           13
        >>   22 POP_BLOCK           
        >>   23 LOAD_CONST               0 (None)
             26 RETURN_VALUE        

Auf der obersten Ebene lautet der Bytecode:

  1           0 SETUP_LOOP              20 (to 23)
              3 LOAD_NAME                0 (xrange)
              6 LOAD_CONST               3 (100000000)
              9 CALL_FUNCTION            1
             12 GET_ITER            
        >>   13 FOR_ITER                 6 (to 22)
             16 STORE_NAME               1 (i)

  2          19 JUMP_ABSOLUTE           13
        >>   22 POP_BLOCK           
        >>   23 LOAD_CONST               2 (None)
             26 RETURN_VALUE        

Der Unterschied ist, dass STORE_FASTes schneller (!) Ist als STORE_NAME. Dies liegt daran, dass eine Funktion ilokal ist, auf oberster Ebene jedoch global.

Verwenden Sie das disModul , um den Bytecode zu überprüfen . Ich konnte die Funktion direkt zerlegen, aber um den obersten Code zu zerlegen, musste ich den compileeingebauten verwenden .

Abgesehen von lokalen / globalen variablen Speicherzeiten beschleunigt die Opcode-Vorhersage die Funktion.

Wie die anderen Antworten erklären, verwendet die Funktion den STORE_FASTOpcode in der Schleife. Hier ist der Bytecode für die Funktionsschleife:

    >>   13 FOR_ITER                 6 (to 22)   # get next value from iterator
         16 STORE_FAST               0 (x)       # set local variable
         19 JUMP_ABSOLUTE           13           # back to FOR_ITER

Normalerweise führt Python beim Ausführen eines Programms jeden Opcode nacheinander aus, verfolgt den Stapel und führt nach Ausführung jedes Opcodes weitere Überprüfungen des Stapelrahmens durch. Opcode-Vorhersage bedeutet, dass Python in bestimmten Fällen direkt zum nächsten Opcode springen kann, wodurch ein Teil dieses Overheads vermieden wird.

In diesem Fall FOR_ITER"sagt" Python jedes Mal, wenn es den oberen Rand der Schleife sieht , voraus, dass dies STORE_FASTder nächste Opcode ist, den es ausführen muss. Python schaut dann auf den nächsten Opcode und springt, wenn die Vorhersage korrekt war, direkt zu STORE_FAST. Dies hat den Effekt, dass die beiden Opcodes zu einem einzigen Opcode zusammengefasst werden.

Auf der anderen Seite die STORE_NAME Opcode in der Schleife auf globaler Ebene verwendet. Python macht * keine * ähnlichen Vorhersagen, wenn es diesen Opcode sieht. Stattdessen muss es zum Anfang der Auswertungsschleife zurückkehren, was offensichtliche Auswirkungen auf die Geschwindigkeit hat, mit der die Schleife ausgeführt wird.

Um weitere technische Details zu dieser Optimierung zu erhalten, finden Sie hier ein Zitat aus dem ceval.c Datei (der "Engine" der virtuellen Maschine von Python):

Einige Opcodes kommen in der Regel paarweise vor, sodass der zweite Code vorhergesagt werden kann, wenn der erste ausgeführt wird. Zum Beispiel GET_ITERwird oft gefolgt von FOR_ITER. Und FOR_ITERwird oft gefolgt vonSTORE_FAST oderUNPACK_SEQUENCE .

Das Überprüfen der Vorhersage kostet einen einzelnen Hochgeschwindigkeitstest einer Registervariablen gegen eine Konstante. Wenn die Paarung gut war, hat die interne Verzweigungsprädikation des Prozessors eine hohe Erfolgswahrscheinlichkeit, was zu einem Übergang von nahezu null Overhead zum nächsten Opcode führt. Eine erfolgreiche Vorhersage erspart eine Reise durch die Bewertungsschleife einschließlich ihrer zwei unvorhersehbaren Zweige, derHAS_ARG Tests und des Schaltfalls. In Kombination mit der internen Verzweigungsvorhersage des Prozessors führt ein Erfolg PREDICTdazu, dass die beiden Opcodes so ausgeführt werden, als wären sie ein einziger neuer Opcode mit den kombinierten Körpern.

Wir können im Quellcode für den FOR_ITEROpcode genau sehen, wo die Vorhersage fürSTORE_FAST gemacht wird:

case FOR_ITER:                         // the FOR_ITER opcode case
    v = TOP();
    x = (*v->ob_type->tp_iternext)(v); // x is the next value from iterator
    if (x != NULL) {                     
        PUSH(x);                       // put x on top of the stack
        PREDICT(STORE_FAST);           // predict STORE_FAST will follow - success!
        PREDICT(UNPACK_SEQUENCE);      // this and everything below is skipped
        continue;
    }
    // error-checking and more code for when the iterator ends normally                                     

Die PREDICTFunktion wird erweitert aufif (*next_instr == op) goto PRED_##op dh wir springen einfach zum Anfang des vorhergesagten Opcodes. In diesem Fall springen wir hier:

PREDICTED_WITH_ARG(STORE_FAST);
case STORE_FAST:
    v = POP();                     // pop x back off the stack
    SETLOCAL(oparg, v);            // set it as the new local variable
    goto fast_next_opcode;

Die lokale Variable ist jetzt gesetzt und der nächste Opcode steht zur Ausführung bereit. Python fährt mit dem Iterable fort, bis es das Ende erreicht, und macht jedes Mal die erfolgreiche Vorhersage.

Auf der Python-Wiki-Seite finden Sie weitere Informationen zur Funktionsweise der virtuellen Maschine von CPython.