¿Es "x <y <z" más rápido que "x <y e y <z"?

Desde esta página , sabemos que:

Las comparaciones encadenadas son más rápidas que usar el andoperador. Escribe en x < y < zlugar de x < y and y < z.

Sin embargo, obtuve un resultado diferente al probar los siguientes fragmentos de código:

$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y < z"
1000000 loops, best of 3: 0.322 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y and y < z"
1000000 loops, best of 3: 0.22 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y < z"
1000000 loops, best of 3: 0.279 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y and y < z"
1000000 loops, best of 3: 0.215 usec per loop

Parece que x < y and y < zes más rápido que x < y < z. ¿Por qué?

Después de buscar algunas publicaciones en este sitio (como este ), sé que "evaluado solo una vez" es la clave x < y < z, sin embargo, todavía estoy confundido. Para seguir estudiando, desarme estas dos funciones usando dis.dis:

import dis

def chained_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y < z

def and_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y and y < z

dis.dis(chained_compare)
dis.dis(and_compare)

Y la salida es:

## chained_compare ##

  4           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

  5           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

  6          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

  7          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 DUP_TOP
             25 ROT_THREE
             26 COMPARE_OP               0 (<)
             29 JUMP_IF_FALSE_OR_POP    41
             32 LOAD_FAST                2 (z)
             35 COMPARE_OP               0 (<)
             38 JUMP_FORWARD             2 (to 43)
        >>   41 ROT_TWO
             42 POP_TOP
        >>   43 POP_TOP
             44 LOAD_CONST               0 (None)
             47 RETURN_VALUE

## and_compare ##

 10           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

 11           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

 12          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

 13          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 COMPARE_OP               0 (<)
             27 JUMP_IF_FALSE_OR_POP    39
             30 LOAD_FAST                1 (y)
             33 LOAD_FAST                2 (z)
             36 COMPARE_OP               0 (<)
        >>   39 POP_TOP
             40 LOAD_CONST               0 (None)

Parece que x < y and y < ztiene menos comandos disimulados que x < y < z. ¿Debo considerar x < y and y < zmás rápido que x < y < z?

Probado con Python 2.7.6 en una CPU Intel (R) Xeon (R) E5640 @ 2.67GHz.

La diferencia es que x < y < z ysolo se evalúa una vez. Esto no hace una gran diferencia si y es una variable, pero lo hace cuando se trata de una llamada de función, lo que lleva algún tiempo calcular.

from time import sleep
def y():
    sleep(.2)
    return 1.3
%timeit 1.2 < y() < 1.8
10 loops, best of 3: 203 ms per loop
%timeit 1.2 < y() and y() < 1.8
1 loops, best of 3: 405 ms per loop

El código de bytes óptimo para las dos funciones que definió sería

          0 LOAD_CONST               0 (None)
          3 RETURN_VALUE

porque el resultado de la comparación no se usa. Hagamos que la situación sea más interesante devolviendo el resultado de la comparación. Tengamos también que el resultado no se pueda conocer en tiempo de compilación.

def interesting_compare(y):
    x = 1.1
    z = 1.3
    return x < y < z  # or: x < y and y < z

Una vez más, las dos versiones de la comparación son semánticamente idénticas, por lo que el código de bytes óptimo es el mismo para ambas construcciones. Lo mejor que puedo resolver, se vería así. He anotado cada línea con el contenido de la pila antes y después de cada código de operación, en notación Forth (la parte superior de la pila a la derecha, --divide antes y después, el seguimiento ?indica algo que podría o no estar allí). Tenga en cuenta que RETURN_VALUEdescarta todo lo que queda en la pila debajo del valor devuelto.

          0 LOAD_FAST                0 (y)    ;          -- y
          3 DUP_TOP                           ; y        -- y y
          4 LOAD_CONST               0 (1.1)  ; y y      -- y y 1.1
          7 COMPARE_OP               4 (>)    ; y y 1.1  -- y pred
         10 JUMP_IF_FALSE_OR_POP     19       ; y pred   -- y
         13 LOAD_CONST               1 (1.3)  ; y        -- y 1.3
         16 COMPARE_OP               0 (<)    ; y 1.3    -- pred
     >>  19 RETURN_VALUE                      ; y? pred  --

Si una implementación del lenguaje, CPython, PyPy, lo que sea, no genera este bytecode (o su propia secuencia equivalente de operaciones) para ambas variaciones, eso demuestra la mala calidad de ese compilador de bytecode . Obtener de las secuencias de código de bytes que publicó en lo anterior es un problema resuelto (creo que todo lo que necesita para este caso es un plegado constante , eliminación de código muerto y un mejor modelado del contenido de la pila; la eliminación de subexpresión común también sería barata y valiosa ), y realmente no hay excusa para no hacerlo en una implementación de lenguaje moderno.

Ahora, sucede que todas las implementaciones actuales del lenguaje tienen compiladores de bytecode de baja calidad. ¡Pero debes ignorar eso mientras codificas! Imagine que el compilador de bytecode es bueno y escriba el código más legible . Probablemente será lo suficientemente rápido de todos modos. Si no es así, busque primero las mejoras algorítmicas y pruebe Cython en segundo lugar; eso proporcionará muchas más mejoras por el mismo esfuerzo que cualquier ajuste de nivel de expresión que pueda aplicar.

Dado que la diferencia en el resultado parece deberse a la falta de optimización, creo que debería ignorar esa diferencia en la mayoría de los casos; podría ser que la diferencia desaparecerá. La diferencia es porque ysolo debe evaluarse una vez y eso se resuelve duplicándolo en la pila, lo que requiere un extra POP_TOP; LOAD_FASTsin embargo , la solución para usar podría ser posible.

Sin embargo, la diferencia importante es que en x<y and y<zel segundo ydebe evaluarse dos veces si se x<yevalúa como verdadero, esto tiene implicaciones si la evaluación ylleva un tiempo considerable o tiene efectos secundarios.

En la mayoría de los escenarios, debe usar a x<y<zpesar de que es algo más lento.

En primer lugar, su comparación no tiene sentido porque las dos construcciones diferentes no se introdujeron para proporcionar una mejora del rendimiento, por lo que no debe decidir si usar una en lugar de la otra en función de eso.

El x < y < zconstructo:

1. Es más claro y más directo en su significado.
2. Su semántica es lo que se espera del "significado matemático" de la comparación: evalute x, yy z una vez y comprobar si toda la condición se cumple. El uso andcambia la semántica al evaluar yvarias veces, lo que puede cambiar el resultado .

Por lo tanto, elija uno en lugar del otro según la semántica que desee y, si son equivalentes, si uno es más legible que el otro.

Dicho esto: un código más desmontado no implica un código más lento. Sin embargo, ejecutar más operaciones de bytecode significa que cada operación es más simple y, sin embargo, requiere una iteración del bucle principal. Esto significa que si las operaciones que está realizando son extremadamente rápidas (por ejemplo, búsqueda de variables locales como lo está haciendo allí), entonces la sobrecarga de ejecutar más operaciones de bytecode puede ser importante.

Pero tenga en cuenta que este resultado no se cumple en la situación más genérica, solo en el "peor de los casos" que le sucede al perfil. Como otros han señalado, si cambias ya algo que lleva incluso un poco más de tiempo, verás que los resultados cambian, porque la notación encadenada lo evalúa solo una vez.

Resumiendo:

• Considere la semántica antes del desempeño.
• Tener en cuenta la legibilidad.
• No confíes en los micro puntos de referencia. Siempre perfile con diferentes tipos de parámetros para ver cómo se comporta una sincronización de función / expresión en relación con dichos parámetros y considere cómo planea usarla.