C'è qualche differenza di prestazioni tra tuple ed elenchi quando si tratta di istanziazione e recupero di elementi?
C'è qualche differenza di prestazioni tra tuple ed elenchi quando si tratta di istanziazione e recupero di elementi?
Risposte:
Il dis
modulo disassembla il codice byte per una funzione ed è utile per vedere la differenza tra tuple ed elenchi.
In questo caso, puoi vedere che l'accesso a un elemento genera un codice identico, ma che assegnare una tupla è molto più veloce che assegnare un elenco.
>>> 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
ListLike
con una __getitem__
che fa qualcosa di orribilmente lento, quindi disassembla x = ListLike((1, 2, 3, 4, 5)); y = x[2]
. Il bytecode sarà più simile all'esempio di tupla sopra che all'esempio di elenco, ma credi davvero che le prestazioni saranno simili?
In generale, potresti aspettarti che le tuple siano leggermente più veloci. Tuttavia, dovresti assolutamente testare il tuo caso specifico (se la differenza potrebbe influire sulle prestazioni del tuo programma, ricorda "l'ottimizzazione prematura è la radice di tutti i mali").
Python lo rende molto semplice: timeit è tuo amico.
$ 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
e...
$ 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
Quindi, in questo caso, l'istanza è quasi un ordine di grandezza più veloce per la tupla, ma l'accesso agli oggetti è in realtà un po 'più veloce per l'elenco! Quindi, se stai creando alcune tuple e accedendo a loro molte volte, in realtà potrebbe essere più veloce usare gli elenchi.
Ovviamente se si desidera modificare un elemento, l'elenco sarà sicuramente più veloce poiché sarebbe necessario creare una tupla completamente nuova per cambiarne uno (poiché le tuple sono immutabili).
python -m timeit "x=tuple(xrange(999999))"
vs python -m timeit "x=list(xrange(999999))"
. Come ci si potrebbe aspettare, ci vuole un po 'più di tempo per materializzare una tupla rispetto a un elenco.
-s "SETUP_CODE"
viene eseguito prima del codice a tempo reale.
Le tuple tendono a funzionare meglio degli elenchi in quasi tutte le categorie:
1) Le tuple possono essere piegate costantemente .
2) Le tuple possono essere riutilizzate anziché copiate.
3) Le tuple sono compatte e non allocano eccessivamente.
4) Le tuple fanno riferimento direttamente ai loro elementi.
Tuple di costanti possono essere pre-calcolate dall'ottimizzatore spioncino di Python o dall'ottimizzatore AST. Gli elenchi, d'altra parte, vengono creati da zero:
>>> 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
La corsa tuple(some_tuple)
ritorna immediatamente se stessa. Poiché le tuple sono immutabili, non devono essere copiate:
>>> a = (10, 20, 30)
>>> b = tuple(a)
>>> a is b
True
Al contrario, list(some_list)
richiede che tutti i dati siano copiati in un nuovo elenco:
>>> a = [10, 20, 30]
>>> b = list(a)
>>> a is b
False
Poiché le dimensioni di una tupla sono fisse, possono essere archiviate in modo più compatto rispetto agli elenchi che devono essere allocati eccessivamente per rendere efficienti le operazioni append () .
Questo dà alle tuple un bel vantaggio di spazio:
>>> import sys
>>> sys.getsizeof(tuple(iter(range(10))))
128
>>> sys.getsizeof(list(iter(range(10))))
200
Ecco il commento da Objects / listobject.c che spiega cosa stanno facendo gli elenchi:
/* 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.
*/
I riferimenti agli oggetti sono incorporati direttamente in un oggetto tupla. Al contrario, gli elenchi hanno un ulteriore livello di riferimento indiretto a una matrice esterna di puntatori.
Ciò offre alle tuple un piccolo vantaggio di velocità per le ricerche indicizzate e il disimballaggio:
$ 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
Ecco come (10, 20)
viene memorizzata la tupla :
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;
Ecco come [10, 20]
viene memorizzato l'elenco :
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;
Si noti che l'oggetto tupla incorpora direttamente i due puntatori di dati mentre l'oggetto elenco ha un ulteriore livello di riferimento indiretto a un array esterno che contiene i due puntatori di dati.
Internally, tuples are stored a little more efficiently than lists, and also tuples can be accessed slightly faster.
Come hai potuto spiegare i risultati dalla risposta di dF. Allora?
tuple(some_tuple)
restituisce some_tuple
se stesso solo se some_tuple
è hash - quando il suo contenuto è ricorsivamente immutabile e hassable. Altrimenti, tuple(some_tuple)
restituisce una nuova tupla. Ad esempio, quando some_tuple
contiene elementi mutabili.
Le tuple, essendo immutabili, sono più efficienti in termini di memoria; elenca, per efficienza, allocazione eccessiva della memoria al fine di consentire aggiunte senza costanti realloc
. Quindi, se vuoi iterare attraverso una sequenza costante di valori nel tuo codice (ad es. for direction in 'up', 'right', 'down', 'left':
), Sono preferite le tuple, poiché tali tuple sono pre-calcolate in tempo di compilazione.
Le velocità di accesso dovrebbero essere le stesse (sono entrambe memorizzate come array contigui nella memoria).
Ma, alist.append(item)
è molto preferito atuple+= (item,)
quando si tratta di dati mutabili. Ricorda che le tuple devono essere trattate come record senza nomi di campo.
Dovresti anche considerare il array
modulo nella libreria standard se tutti gli elementi nella tua lista o tupla sono dello stesso tipo C. Ci vorrà meno memoria e può essere più veloce.
Ecco un altro piccolo punto di riferimento, solo per il gusto di farlo ..
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)
Facciamo una media di questi:
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
Puoi chiamarlo quasi inconcludente.
Ma certo, le tuple hanno impiegato 101.239%
del tempo o 1.239%
tempo extra per fare il lavoro rispetto alle liste.
Le tuple dovrebbero essere leggermente più efficienti e per questo, più veloci degli elenchi perché sono immutabili.
Il motivo principale per cui Tuple è molto efficiente nella lettura è perché è immutabile.
Il motivo è che le tuple possono essere archiviate nella cache di memoria, a differenza degli elenchi. Il programma legge sempre dalla posizione della memoria degli elenchi in quanto è modificabile (può cambiare in qualsiasi momento).