Ho circa 10 milioni di valori che devo inserire in un tipo di tabella di ricerca, quindi mi chiedevo quale sarebbe stato un elenco o un dict più efficiente ?

So che puoi fare qualcosa del genere per entrambi:

if something in dict_of_stuff:
    pass

e

if something in list_of_stuff:
    pass

Il mio pensiero è che il dict sarà più veloce ed efficiente.

Grazie per l'aiuto.

EDIT 1
Ulteriori informazioni su ciò che sto cercando di fare. Problema di Eulero 92 . Sto creando una tabella di ricerca per vedere se un valore calcolato è già stato calcolato.

EDIT 2
Efficienza per cercare.

EDIT 3
Non ci sono valori associati al valore ... quindi un set sarebbe migliore?

Velocità

Le ricerche negli elenchi sono O (n), le ricerche nei dizionari sono ammortizzate O (1), in relazione al numero di elementi nella struttura dei dati. Se non è necessario associare valori, utilizzare i set.

Memoria

Sia i dizionari che i set usano l'hashing e usano molta più memoria che solo per l'archiviazione degli oggetti. Secondo AM Kuchling in Beautiful Code , l'implementazione cerca di mantenere pieno l'hash 2/3, quindi potresti perdere un po 'di memoria.

Se non aggiungi nuove voci al volo (cosa che fai, in base alla tua domanda aggiornata), potrebbe essere utile ordinare l'elenco e utilizzare la ricerca binaria. Questo è O (log n), ed è probabilmente più lento per le stringhe, impossibile per gli oggetti che non hanno un ordinamento naturale.

Un dict è una tabella hash, quindi è molto veloce trovare le chiavi. Quindi tra dict e list, dict sarebbe più veloce. Ma se non hai un valore da associare, è ancora meglio usare un set. È una tabella hash, senza la parte "table".

EDIT: per la tua nuova domanda, SÌ, un set sarebbe meglio. Basta creare 2 set, uno per le sequenze terminate in 1 e l'altro per le sequenze terminate in 89. Ho risolto con successo questo problema utilizzando i set.

set()è esattamente quello che vuoi. O (1) ricerche e più piccolo di un dict.

Ho fatto alcuni benchmarking e risulta che dict è più veloce di entrambi gli elenchi e impostato per grandi set di dati, eseguendo python 2.7.3 su una CPU i7 su Linux:

• python -mtimeit -s 'd=range(10**7)' '5*10**6 in d'

  10 loop, meglio di 3: 64,2 msec per loop

• python -mtimeit -s 'd=dict.fromkeys(range(10**7))' '5*10**6 in d'

  10000000 loop, meglio di 3: 0,0759 usec per loop

• python -mtimeit -s 'from sets import Set; d=Set(range(10**7))' '5*10**6 in d'

  1000000 loop, meglio di 3: 0,262 usec per loop

Come puoi vedere, dict è considerevolmente più veloce della lista e circa 3 volte più veloce di quanto impostato. In alcune applicazioni potresti comunque voler scegliere set per la sua bellezza. E se i set di dati sono veramente piccoli (<1000 elementi) gli elenchi funzionano abbastanza bene.

Vuoi un dict.

Per gli elenchi (non ordinati) in Python, l'operazione "in" richiede O (n) time --- non va bene quando si dispone di una grande quantità di dati. Un dict, d'altra parte, è una tabella hash, quindi puoi aspettarti un tempo di ricerca O (1).

Come altri hanno già notato, potresti scegliere un set (un tipo speciale di dict), invece, se hai solo chiavi anziché coppie chiave / valore.

Relazionato:

• Wiki Python : informazioni sulla complessità temporale delle operazioni del contenitore Python.
• SO : tempo di funzionamento del contenitore Python e complessità della memoria

se i dati sono univoci set () sarà il più efficiente, ma di due-dict (che richiede anche unicità, oops :)

Come una nuova serie di test per mostrare @ EriF89 è ancora giusto dopo tutti questi anni:

$ python -m timeit -s "l={k:k for k in xrange(5000)}"    "[i for i in xrange(10000) if i in l]"
1000 loops, best of 3: 1.84 msec per loop
$ python -m timeit -s "l=[k for k in xrange(5000)]"    "[i for i in xrange(10000) if i in l]"
10 loops, best of 3: 573 msec per loop
$ python -m timeit -s "l=tuple([k for k in xrange(5000)])"    "[i for i in xrange(10000) if i in l]"
10 loops, best of 3: 587 msec per loop
$ python -m timeit -s "l=set([k for k in xrange(5000)])"    "[i for i in xrange(10000) if i in l]"
1000 loops, best of 3: 1.88 msec per loop

Qui confrontiamo anche a tuple, che sono noti per essere più veloci di lists(e usano meno memoria) in alcuni casi d'uso. Nel caso della tabella di ricerca, iltuple premio non è migliore.

Sia il dictche ilset comportato molto bene. Questo fa emergere un punto interessante legato alla risposta di @SilentGhost sull'unicità: se l'OP ha valori 10M in un set di dati, ed è sconosciuto se ci sono duplicati in essi, varrebbe la pena mantenere un set / dict dei suoi elementi in parallelo con il set di dati effettivo e test per l'esistenza in tale set / dict. È possibile che i punti dati 10M abbiano solo 10 valori univoci, che è uno spazio molto più piccolo per la ricerca!

L'errore di SilentGhost sui dicts è in realtà illuminante perché si potrebbe usare un dict per correlare i dati duplicati (in valori) in un set non duplicato (chiavi), e quindi mantenere un oggetto dati per contenere tutti i dati, ma essere comunque veloce come una tabella di ricerca. Ad esempio, una chiave di dettatura potrebbe essere il valore che viene cercato e il valore potrebbe essere un elenco di indici in un elenco immaginario in cui si è verificato quel valore.

Ad esempio, se l'elenco dei dati di origine da cercare era l=[1,2,3,1,2,1,4], potrebbe essere ottimizzato sia per la ricerca che per la memoria sostituendolo con questo dict:

>>> from collections import defaultdict
>>> d = defaultdict(list)
>>> l=[1,2,3,1,2,1,4]
>>> for i, e in enumerate(l):
...     d[e].append(i)
>>> d
defaultdict(<class 'list'>, {1: [0, 3, 5], 2: [1, 4], 3: [2], 4: [6]})

Con questo detto, si può sapere:

1. Se un valore era nel set di dati originale (ovvero 2 in drestituisce True)
2. Dove il valore era di dati originale (cioè d[2]restituisce elenco degli indici in cui i dati è stato trovato nella lista dati originali: [1, 4])

In realtà non è necessario memorizzare 10 milioni di valori nella tabella, quindi non è un grosso problema in entrambi i casi.

Suggerimento: pensa a quanto può essere grande il tuo risultato dopo la prima somma delle operazioni dei quadrati. Il risultato più grande possibile sarà molto più piccolo di 10 milioni ...