Perché il codice Python viene eseguito più velocemente in una funzione?

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

Questo pezzo di codice in Python viene eseguito (Nota: il tempismo viene eseguito con la funzione time in BASH in Linux.)

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

Tuttavia, se il ciclo for non è inserito in una funzione,

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

quindi funziona per un tempo molto più lungo:

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

Perchè è questo?

Potresti chiederti perché è più veloce memorizzare variabili locali rispetto ai globali. Questo è un dettaglio dell'implementazione di CPython.

Ricorda che CPython è compilato in bytecode, che viene eseguito dall'interprete. Quando viene compilata una funzione, le variabili locali vengono archiviate in un array di dimensioni fisse ( non a dict) e i nomi delle variabili vengono assegnati agli indici. Ciò è possibile perché non è possibile aggiungere dinamicamente variabili locali a una funzione. Quindi il recupero di una variabile locale è letteralmente una ricerca del puntatore nell'elenco e un aumento del conteggio su PyObjectquale è banale.

Confrontalo con una ricerca globale ( LOAD_GLOBAL), che è una vera dictricerca che coinvolge un hash e così via. Per inciso, questo è il motivo per cui è necessario specificare global ise si desidera che sia globale: se mai si assegna a una variabile all'interno di un ambito, il compilatore emetterà STORE_FASTs per il suo accesso a meno che non gli si dica di non farlo.

A proposito, le ricerche globali sono ancora piuttosto ottimizzate. Le ricerche di attributi foo.barsono davvero lente!

Ecco una piccola illustrazione sull'efficienza delle variabili locali.

All'interno di una funzione, il 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        

Al livello superiore, il 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        

La differenza è che STORE_FASTè più veloce (!) Rispetto STORE_NAME. Questo perché in una funzione iè locale ma a livello superiore è globale.

Per esaminare il bytecode, utilizzare il dismodulo . Sono stato in grado di disassemblare direttamente la funzione, ma per smontare il codice di livello superiore ho dovuto usare l' compileintegrato .

A parte i tempi di memorizzazione variabili locali / globali, la previsione del codice operativo rende la funzione più veloce.

Come spiegano le altre risposte, la funzione utilizza il STORE_FASTcodice operativo nel ciclo. Ecco il bytecode per il loop della funzione:

    >>   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

Normalmente quando viene eseguito un programma, Python esegue ogni codice operativo uno dopo l'altro, tenendo traccia dello stack e preformando altri controlli sul frame dello stack dopo l'esecuzione di ciascun codice operativo. La previsione di Opcode significa che in alcuni casi Python è in grado di passare direttamente al successivo opcode, evitando così un certo sovraccarico.

In questo caso, ogni volta che Python vede FOR_ITER(la parte superiore del ciclo), "prevede" STORE_FASTil prossimo opcode che deve eseguire. Python quindi dà un'occhiata al successivo codice operativo e, se la previsione era corretta, passa direttamente a STORE_FAST. Ciò ha l'effetto di spremere i due codici operativi in ​​un unico codice operativo.

D'altra parte, il STORE_NAMEcodice operativo viene utilizzato nel ciclo a livello globale. Python * non * fa previsioni simili quando vede questo codice operativo. Invece, deve tornare all'inizio del ciclo di valutazione che ha ovvie implicazioni per la velocità con cui il ciclo viene eseguito.

Per fornire ulteriori dettagli tecnici su questa ottimizzazione, ecco una citazione dal ceval.cfile (il "motore" della macchina virtuale di Python):

Alcuni codici operativi tendono a venire in coppia, rendendo così possibile prevedere il secondo codice quando viene eseguito il primo. Ad esempio, GET_ITERè spesso seguito da FOR_ITER. Ed FOR_ITERè spesso seguito daSTORE_FAST o UNPACK_SEQUENCE.

La verifica della previsione costa un singolo test ad alta velocità di una variabile di registro rispetto a una costante. Se l'accoppiamento è andato a buon fine, la previsione della diramazione interna del processore ha un'elevata probabilità di successo, con una transizione quasi zero al successivo opcode. Una previsione riuscita salva un viaggio attraverso il circuito di valutazione inclusi i suoi due rami imprevedibili, il HAS_ARGtest e la custodia. In combinazione con la previsione del ramo interno del processore, un successo PREDICTha l'effetto di far funzionare i due codici operativi come se fossero un unico nuovo codice operativo con i corpi combinati.

Possiamo vedere nel codice sorgente per il codice FOR_ITERoperativo esattamente dove STORE_FASTviene fatta la previsione :

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                                     

La PREDICTfunzione si espande, if (*next_instr == op) goto PRED_##opovvero passiamo all'inizio dell'opcode previsto. In questo caso, saltiamo qui:

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;

La variabile locale è ora impostata e il successivo opcode è pronto per l'esecuzione. Python continua attraverso l'iterabile fino a raggiungere la fine, facendo ogni volta la previsione riuscita.

La pagina wiki di Python contiene ulteriori informazioni su come funziona la macchina virtuale di CPython.