[pyar] Me recomiendan un diccionario?

[Claudio Freire]

2014-02-28 11:33 GMT-03:00 Daniel Moisset <dmoisset en machinalis.com>:
> 2014-02-27 19:39 GMT-03:00 Gustavo Campanelli <gedece en gmail.com>:
>>
>>
>> Segunda consulta ¿Podes generar datos en varios grupos separados o hay que
>> generarlos todos de un saque por alguna razón distinta a "Comodidad"?
>>
>> Gedece
>
>
>
> No los puedo generar separados; vienen de algo stream-like de una fuente
> externa. No es realtime, puedo parar al medio y luego continuar.
>
> Pero el approach en base a esto que me dijo Angel no me sirve mucho, si leo
> la mitad de los datos a generar, la segunda parte del algoritmo me va a
> fallar cuando no encuentre valores (realmente no tengo como saber en que
> orden va a ser los lookups), y como la segunda parte del algoritmo computa
> algo en base a todo, hacer el algoritmo para que se banque los "agujeros" en
> el diccionario y se pueda a hacer en dos pasadas, no cierra. Lo hago si no
> queda otra, y ese tipo de cosas es el plan B. Escribi a la lista mas que
> nada para ver si habia un plan A
>
> En más novedades:
>
> Probé con bdb. Anduvo bastante bien por un rato (entre 2x y 3x la velocidad
> de redis). Pero a medida que empezó a crecer el mapa (cuando iba por unos
> pocos millones de registros) se enlentenció mucho (0.2x la velocidad de
> redis). Así que también descarté eso.


Interesante. Usaste btree o hash?

Yo dispararía por: o buscarle la vuelta a bdb, o probar con hamsterdb.

Lo que describís suena a I/O. Es posible que te convenga jugar con los
parámetros de bdb para hacer la I/O lo más amigable posible. Por
ejemplo, abrir en "fast" mode o cosas por el estilo.

También, aunque dicen que hash es mejor porque blah o bleh, puede no
ser verdadero. Habría que probar ambos.

Y, obviamente, python tiene muchas implementaciones de bdb. Hay una
simple, una basada en gdbm, otra en la de oracle... es más que
probable que las performances no sean del todo equivalentes.