it-swarm-es.tech

¿Son las tuplas más eficientes que las listas en Python?

¿Hay alguna diferencia de rendimiento entre tuplas y listas cuando se trata de la creación de instancias y la recuperación de elementos?

181
Readonly

El módulo dis desmonta el código de byte para una función y es útil para ver la diferencia entre tuplas y listas.

En este caso, puede ver que acceder a un elemento genera un código idéntico, pero que asignar una Tupla es mucho más rápido que asignar una lista.

>>> def a():
...     x=[1,2,3,4,5]
...     y=x[2]
...
>>> def b():
...     x=(1,2,3,4,5)
...     y=x[2]
...
>>> import dis
>>> dis.dis(a)
  2           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2)
              6 LOAD_CONST               3 (3)
              9 LOAD_CONST               4 (4)
             12 LOAD_CONST               5 (5)
             15 BUILD_LIST               5
             18 STORE_FAST               0 (x)

  3          21 LOAD_FAST                0 (x)
             24 LOAD_CONST               2 (2)
             27 BINARY_SUBSCR
             28 STORE_FAST               1 (y)
             31 LOAD_CONST               0 (None)
             34 RETURN_VALUE
>>> dis.dis(b)
  2           0 LOAD_CONST               6 ((1, 2, 3, 4, 5))
              3 STORE_FAST               0 (x)

  3           6 LOAD_FAST                0 (x)
              9 LOAD_CONST               2 (2)
             12 BINARY_SUBSCR
             13 STORE_FAST               1 (y)
             16 LOAD_CONST               0 (None)
             19 RETURN_VALUE
149
Mark Harrison

En general, es de esperar que las tuplas sean un poco más rápidas. Sin embargo, definitivamente debe probar su caso específico (si la diferencia puede afectar el rendimiento de su programa, recuerde que "la optimización prematura es la raíz de todo mal").

Python lo hace muy fácil: timeit es tu amigo.

$ python -m timeit "x=(1,2,3,4,5,6,7,8)"
10000000 loops, best of 3: 0.0388 usec per loop

$ python -m timeit "x=[1,2,3,4,5,6,7,8]"
1000000 loops, best of 3: 0.363 usec per loop

y...

$ python -m timeit -s "x=(1,2,3,4,5,6,7,8)" "y=x[3]"
10000000 loops, best of 3: 0.0938 usec per loop

$ python -m timeit -s "x=[1,2,3,4,5,6,7,8]" "y=x[3]"
10000000 loops, best of 3: 0.0649 usec per loop

Entonces, en este caso, la creación de instancias es casi un orden de magnitud más rápido para el Tuple, ¡pero el acceso a los elementos es en realidad algo más rápido para la lista! Por lo tanto, si está creando unas pocas tuplas y las está accediendo muchas veces, puede que en realidad sea más rápido usar listas.

Por supuesto, si desea cambiar un elemento, la lista definitivamente será más rápida, ya que tendrá que crear una tupla nueva para cambiar un elemento (ya que las tuplas son inmutables).

190
dF.

Resumen

Las tuplas tienden a funcionar mejor que las listas en casi todas las categorías:

1) Las tuplas pueden ser plegadas constantemente .

2) Las tuplas se pueden reutilizar en lugar de copiar.

3) Las tuplas son compactas y no se sobre-asignan.

4) Las tuplas hacen referencia directa a sus elementos.

Las tuplas se pueden plegar constantemente

Las tuplas de constantes pueden precomputarse con el optimizador de mirilla de Python o el optimizador de AST. Las listas, por otro lado, se acumulan desde cero:

    >>> from dis import dis

    >>> dis(compile("(10, 'abc')", '', 'eval'))
      1           0 LOAD_CONST               2 ((10, 'abc'))
                  3 RETURN_VALUE   

    >>> dis(compile("[10, 'abc']", '', 'eval'))
      1           0 LOAD_CONST               0 (10)
                  3 LOAD_CONST               1 ('abc')
                  6 BUILD_LIST               2
                  9 RETURN_VALUE 

Las tuplas no necesitan ser copiadas

Ejecutando Tuple(some_Tuple) vuelve inmediatamente a sí mismo. Dado que las tuplas son inmutables, no es necesario copiarlas:

>>> a = (10, 20, 30)
>>> b = Tuple(a)
>>> a is b
True

En contraste, list(some_list) requiere que todos los datos se copien a una nueva lista:

>>> a = [10, 20, 30]
>>> b = list(a)
>>> a is b
False

Las tuplas no se sobre-asignan

Dado que el tamaño de una Tupla es fijo, puede almacenarse de manera más compacta que las listas que necesitan asignarse en exceso para que append () son eficientes en operaciones.

Esto le da a las tuplas una ventaja de espacio agradable:

>>> import sys
>>> sys.getsizeof(Tuple(iter(range(10))))
128
>>> sys.getsizeof(list(iter(range(10))))
200

Aquí está el comentario de Objects/listobject.c que explica lo que están haciendo las listas:

/* This over-allocates proportional to the list size, making room
 * for additional growth.  The over-allocation is mild, but is
 * enough to give linear-time amortized behavior over a long
 * sequence of appends() in the presence of a poorly-performing
 * system realloc().
 * The growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
 * Note: new_allocated won't overflow because the largest possible value
 *       is PY_SSIZE_T_MAX * (9 / 8) + 6 which always fits in a size_t.
 */

Las tuplas se refieren directamente a sus elementos.

Las referencias a los objetos se incorporan directamente en un objeto Tuple. En contraste, las listas tienen una capa adicional de direccionamiento indirecto a una matriz externa de punteros.

Esto le da a las tuplas una pequeña ventaja de velocidad para búsquedas indexadas y desempaquetado:

$ python3.6 -m timeit -s 'a = (10, 20, 30)' 'a[1]'
10000000 loops, best of 3: 0.0304 usec per loop
$ python3.6 -m timeit -s 'a = [10, 20, 30]' 'a[1]'
10000000 loops, best of 3: 0.0309 usec per loop

$ python3.6 -m timeit -s 'a = (10, 20, 30)' 'x, y, z = a'
10000000 loops, best of 3: 0.0249 usec per loop
$ python3.6 -m timeit -s 'a = [10, 20, 30]' 'x, y, z = a'
10000000 loops, best of 3: 0.0251 usec per loop

Aquí es cómo se almacena el Tuple (10, 20):

    typedef struct {
        Py_ssize_t ob_refcnt;
        struct _typeobject *ob_type;
        Py_ssize_t ob_size;
        PyObject *ob_item[2];     /* store a pointer to 10 and a pointer to 20 */
    } PyTupleObject;

Aquí es cómo se almacena la lista [10, 20]:

    PyObject arr[2];              /* store a pointer to 10 and a pointer to 20 */

    typedef struct {
        Py_ssize_t ob_refcnt;
        struct _typeobject *ob_type;
        Py_ssize_t ob_size;
        PyObject **ob_item = arr; /* store a pointer to the two-pointer array */
        Py_ssize_t allocated;
    } PyListObject;

Tenga en cuenta que el objeto Tuple incorpora los dos punteros de datos directamente, mientras que el objeto de lista tiene una capa adicional de direccionamiento indirecto a una matriz externa que contiene los dos punteros de datos.

159

Las tuplas, al ser inmutables, son más eficientes en memoria las listas, para mayor eficiencia, ubican la memoria para permitir los apéndices sin constantes reallocs. Por lo tanto, si desea iterar a través de una secuencia constante de valores en su código (por ejemplo, for direction in 'up', 'right', 'down', 'left':), se prefieren las tuplas, ya que dichas tuplas se calculan previamente en tiempo de compilación.

Las velocidades de acceso deben ser las mismas (ambas se almacenan como matrices contiguas en la memoria).

Pero, alist.append(item) es mucho más preferido que atuple+= (item,) cuando se trata de datos mutables. Recuerde, las tuplas están diseñadas para ser tratadas como registros sin nombres de campo.

31
tzot

También debe considerar el módulo array en la biblioteca estándar si todos los elementos de su lista o Tuple son del mismo tipo C. Tomará menos memoria y puede ser más rápido.

9
Ralph Corderoy

Las tuplas deberían ser un poco más eficientes y, por eso, más rápidas que las listas porque son inmutables.

4
ctcherry

Aquí hay otro pequeño punto de referencia, solo por el bien de esto ...

In [11]: %timeit list(range(100))
749 ns ± 2.41 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [12]: %timeit Tuple(range(100))
781 ns ± 3.34 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [1]: %timeit list(range(1_000))
13.5 µs ± 466 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [2]: %timeit Tuple(range(1_000))
12.4 µs ± 182 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [7]: %timeit list(range(10_000))
182 µs ± 810 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [8]: %timeit Tuple(range(10_000))
188 µs ± 2.38 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [3]: %timeit list(range(1_00_000))
2.76 ms ± 30.5 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [4]: %timeit Tuple(range(1_00_000))
2.74 ms ± 31.8 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [10]: %timeit list(range(10_00_000))
28.1 ms ± 266 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [9]: %timeit Tuple(range(10_00_000))
28.5 ms ± 447 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

Vamos a promediar estos:

In [3]: l = np.array([749 * 10 ** -9, 13.5 * 10 ** -6, 182 * 10 ** -6, 2.76 * 10 ** -3, 28.1 * 10 ** -3])

In [2]: t = np.array([781 * 10 ** -9, 12.4 * 10 ** -6, 188 * 10 ** -6, 2.74 * 10 ** -3, 28.5 * 10 ** -3])

In [11]: np.average(l)
Out[11]: 0.0062112498000000006

In [12]: np.average(t)
Out[12]: 0.0062882362

In [17]: np.average(t) / np.average(l)  * 100
Out[17]: 101.23946713590554

Puedes llamarlo casi inconcluso.

Pero claro, las tuplas tomaron 101.239% el tiempo, o 1.239% tiempo adicional para hacer el trabajo en comparación con las listas.

2
Dev Aggarwal