Por que o código Python roda mais rápido em uma função?

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

Este trecho de código no Python é executado (Observação: o tempo é feito com a função de tempo no BASH no Linux.)

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

No entanto, se o loop for não for colocado em uma função,

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

então ele roda por um tempo muito maior:

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

Por que é isso?

Você pode perguntar por que é mais rápido armazenar variáveis ​​locais do que globais. Este é um detalhe de implementação do CPython.

Lembre-se de que o CPython é compilado no bytecode, que o interpretador executa. Quando uma função é compilada, as variáveis ​​locais são armazenadas em uma matriz de tamanho fixo ( não a dict) e os nomes das variáveis ​​são atribuídos aos índices. Isso é possível porque você não pode adicionar dinamicamente variáveis ​​locais a uma função. A recuperação de uma variável local é literalmente uma pesquisa de ponteiro na lista e um aumento de refcount no PyObjectque é trivial.

Compare isso com uma pesquisa global ( LOAD_GLOBAL), que é uma verdadeira dictpesquisa envolvendo um hash e assim por diante. Aliás, é por isso que você precisa especificar global ise deseja que seja global: se você atribuir a uma variável dentro de um escopo, o compilador emitirá STORE_FASTs para seu acesso, a menos que você o solicite.

A propósito, as pesquisas globais ainda são bastante otimizadas. As pesquisas de atributos foo.barsão realmente lentas!

Aqui está uma pequena ilustração sobre a eficiência variável local.

Dentro de uma função, o 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        

No nível superior, o 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        

A diferença é que STORE_FASTé mais rápido (!) Que STORE_NAME. Isso ocorre porque em uma função ié local, mas no nível superior é global.

Para examinar bytecode, use o dismódulo . Consegui desmontar a função diretamente, mas para desmontar o código de nível superior, tive que usar o compilebuiltin .

Além dos tempos de armazenamento variáveis ​​locais / globais, a previsão do código de operação torna a função mais rápida.

Como as outras respostas explicam, a função usa o STORE_FASTcódigo de operação no loop. Aqui está o bytecode para o loop da função:

    >>   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 um programa é executado, o Python executa cada código de operação um após o outro, acompanhando a pilha e pré-formando outras verificações no quadro da pilha após a execução de cada código de operação. A previsão de código de operação significa que, em certos casos, o Python é capaz de pular diretamente para o próximo código de operação, evitando parte dessa sobrecarga.

Nesse caso, toda vez que o Python vir FOR_ITER(a parte superior do loop), ele "prediz" que STORE_FASTé o próximo opcode que ele deve executar. O Python então espreita o próximo código de operação e, se a previsão estiver correta, salta diretamente para STORE_FAST. Isso tem o efeito de espremer os dois códigos de operação em um único código de operação.

Por outro lado, o STORE_NAMEcódigo de operação é usado no loop em nível global. O Python * não * faz previsões semelhantes quando vê esse opcode. Em vez disso, ele deve voltar ao topo do loop de avaliação, o que tem implicações óbvias para a velocidade com que o loop é executado.

Para fornecer mais detalhes técnicos sobre essa otimização, aqui está uma citação do ceval.carquivo (o "mecanismo" da máquina virtual do Python):

Alguns opcodes tendem a vir em pares, tornando possível prever o segundo código quando o primeiro é executado. Por exemplo, GET_ITERgeralmente é seguido por FOR_ITER. E FOR_ITERé frequentemente seguido porSTORE_FAST ou UNPACK_SEQUENCE.

Verificar a previsão custa um único teste de alta velocidade de uma variável de registro em relação a uma constante. Se o emparelhamento foi bom, a predicação de ramificação interna do próprio processador tem uma alta probabilidade de sucesso, resultando em uma transição quase zero para o próximo código de operação. Uma previsão bem-sucedida salva uma viagem pelo loop de avaliação, incluindo seus dois ramos imprevisíveis, o HAS_ARGteste e o caso do switch. Combinado com a previsão de ramificação interna do processador, um êxito PREDICTtem o efeito de executar os dois opcodes como se fossem um único novo opcode com os corpos combinados.

Podemos ver no código fonte do FOR_ITERopcode exatamente onde a previsão STORE_FASTé feita:

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                                     

A PREDICTfunção se expande para, if (*next_instr == op) goto PRED_##opou seja, apenas saltamos para o início do código de operação previsto. Nesse caso, pulamos aqui:

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;

A variável local está agora definida e o próximo opcode está pronto para execução. O Python continua pelo iterável até chegar ao fim, fazendo a previsão bem-sucedida a cada vez.

A página wiki do Python tem mais informações sobre como a máquina virtual do CPython funciona.