Buscar en colecciones

supongo que algún problema de indices tenés... pero esto que digo es tan una trivialidad que seguro ya lo intentaste: armar un btree ordenado según el índice por el cual buscas los duplicados?

Saludos,

E

El 03/11/2010, a las 4:04p.m., Norberto Manzanos escribió:

Muchachos ( y no tanto) de ClubSmalltalk

Tengo un problema bastante grande y quería ver si alguien me puede dar un consejo.
Tengo una colección de datos en archivos (no es exactamente una base de datos, pero parecido) entre los cuales hay duplicados. Los duplicados no son triviales, hay que hacer algunas cosas para detectarlos, pero ese no es el punto.
Una vez que estos datos estén normalizados pueden persistirse de varias formas, tampoco ese es el problema.
El cuello de botella es la búsqueda en las colecciones. Probé colecciones en memoria, colecciones Magma, Sandstone y el problema es siempre el mismo: el tiempo que tarda la búsqueda. Magma, que fue lo más eficiente, podría llegar a tardar 2 o 3 días para procesar 76000 registros. Un proceso similar, aunque con objetos más complicados, me tardó 2 semanas hace un tiempo. Los de Magma siempre me dicen que algo mal debo estar haciendo, pero nunca aparece que es eso que está mal. No creo estar haciendo nada que pueda hacer que un proceso que debería tardar algunas horas tarde varios días o más.
Estoy a punto de intentar con una base SQL, lo cual me deprime mucho.
¿Alguien conoce algo para Squeak que permita detectar elementos en colecciones en forma más eficiente? ¿Algún truco al menos?

Gracias

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Tambien podes implementar #= y #hash de alguna manera que corresponda,
y poner todo en un Set...

2010/11/3 Esteban Lorenzano <[hidden email]>:

> supongo que algún problema de indices tenés... pero esto que digo es tan una
> trivialidad que seguro ya lo intentaste: armar un btree ordenado según el
> índice por el cual buscas los duplicados?
> Saludos,
> E
>
> El 03/11/2010, a las 4:04p.m., Norberto Manzanos escribió:
>
> Muchachos ( y no tanto) de ClubSmalltalk
>
> Tengo un problema bastante grande y quería ver si alguien me puede dar un
> consejo.
> Tengo una colección de datos en archivos (no es exactamente una base de
> datos, pero parecido) entre los cuales hay duplicados. Los duplicados no son
> triviales, hay que hacer algunas cosas para detectarlos, pero ese no es el
> punto.
> Una vez que estos datos estén normalizados pueden persistirse de varias
> formas, tampoco ese es el problema.
> El cuello de botella es la búsqueda en las colecciones. Probé colecciones en
> memoria, colecciones Magma, Sandstone y el problema es siempre el mismo: el
> tiempo que tarda la búsqueda. Magma, que fue lo más eficiente, podría llegar
> a tardar 2 o 3 días para procesar 76000 registros. Un proceso similar,
> aunque con objetos más complicados, me tardó 2 semanas hace un tiempo. Los
> de Magma siempre me dicen que algo mal debo estar haciendo, pero nunca
> aparece que es eso que está mal. No creo estar haciendo nada que pueda hacer
> que un proceso que debería tardar algunas horas tarde varios días o más.
> Estoy a punto de intentar con una base SQL, lo cual me deprime mucho.
> ¿Alguien conoce algo para Squeak que permita detectar elementos en
> colecciones en forma más eficiente? ¿Algún truco al menos?
>
> Gracias
>
> --
> Norberto Manzanos
> Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
> FaHCE/UNLP - CONICET
> Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
> Tel: +54-221-4230125 interno 262
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

El problema lo estas teniendo en la búsqueda en las colecciones ?? hiciste un profiling y encontraste que ese el punto?? o el acceso a la info.. La busqueda esta muy optimizada. Como dijo Andres reimplementando eso 2 metodos debería andar muy rapido.

Tengo una aplicación productiva que tiene ciento de miles de objetos en una colección y la busqueda no llega a segundos.

Saludos.

2010/11/3 Andres Valloud <[hidden email]>

Tambien podes implementar #= y #hash de alguna manera que corresponda,

y poner todo en un Set...

2010/11/3 Esteban Lorenzano <[hidden email]>:

> supongo que algún problema de indices tenés... pero esto que digo es tan una
> trivialidad que seguro ya lo intentaste: armar un btree ordenado según el
> índice por el cual buscas los duplicados?
> Saludos,
> E
>
> El 03/11/2010, a las 4:04p.m., Norberto Manzanos escribió:
>
> Muchachos ( y no tanto) de ClubSmalltalk
>
> Tengo un problema bastante grande y quería ver si alguien me puede dar un
> consejo.
> Tengo una colección de datos en archivos (no es exactamente una base de
> datos, pero parecido) entre los cuales hay duplicados. Los duplicados no son
> triviales, hay que hacer algunas cosas para detectarlos, pero ese no es el
> punto.
> Una vez que estos datos estén normalizados pueden persistirse de varias
> formas, tampoco ese es el problema.
> El cuello de botella es la búsqueda en las colecciones. Probé colecciones en
> memoria, colecciones Magma, Sandstone y el problema es siempre el mismo: el
> tiempo que tarda la búsqueda. Magma, que fue lo más eficiente, podría llegar
> a tardar 2 o 3 días para procesar 76000 registros. Un proceso similar,
> aunque con objetos más complicados, me tardó 2 semanas hace un tiempo. Los
> de Magma siempre me dicen que algo mal debo estar haciendo, pero nunca
> aparece que es eso que está mal. No creo estar haciendo nada que pueda hacer
> que un proceso que debería tardar algunas horas tarde varios días o más.
> Estoy a punto de intentar con una base SQL, lo cual me deprime mucho.
> ¿Alguien conoce algo para Squeak que permita detectar elementos en
> colecciones en forma más eficiente? ¿Algún truco al menos?
>
> Gracias
>
> --
> Norberto Manzanos
> Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
> FaHCE/UNLP - CONICET
> Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
> Tel: +54-221-4230125 interno 262
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Norberto,

para buscar en una MagmaCollection usaste where: y configuraste los indices? Todavía no probé con 76000 registros, voy a probar.

Abrazo

2010/11/3 Norberto Manzanos <[hidden email]>

No, la verdad que no lo probé. Confié demasiado en que esa tarea la haría Magma. Voy a probarlo. Gracias.

2010/11/3 Esteban Lorenzano <[hidden email]>

supongo que algún problema de indices tenés... pero esto que digo es tan una trivialidad que seguro ya lo intentaste: armar un btree ordenado según el índice por el cual buscas los duplicados?

Saludos,

E

El 03/11/2010, a las 4:04p.m., Norberto Manzanos escribió:

Muchachos ( y no tanto) de ClubSmalltalk

Tengo un problema bastante grande y quería ver si alguien me puede dar un consejo.
Tengo una colección de datos en archivos (no es exactamente una base de datos, pero parecido) entre los cuales hay duplicados. Los duplicados no son triviales, hay que hacer algunas cosas para detectarlos, pero ese no es el punto.
Una vez que estos datos estén normalizados pueden persistirse de varias formas, tampoco ese es el problema.
El cuello de botella es la búsqueda en las colecciones. Probé colecciones en memoria, colecciones Magma, Sandstone y el problema es siempre el mismo: el tiempo que tarda la búsqueda. Magma, que fue lo más eficiente, podría llegar a tardar 2 o 3 días para procesar 76000 registros. Un proceso similar, aunque con objetos más complicados, me tardó 2 semanas hace un tiempo. Los de Magma siempre me dicen que algo mal debo estar haciendo, pero nunca aparece que es eso que está mal. No creo estar haciendo nada que pueda hacer que un proceso que debería tardar algunas horas tarde varios días o más.
Estoy a punto de intentar con una base SQL, lo cual me deprime mucho.
¿Alguien conoce algo para Squeak que permita detectar elementos en colecciones en forma más eficiente? ¿Algún truco al menos?

Gracias

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Pregunta.. cuando encontras un duplicado los sacas de la collection de magma ??

Mira que magma tiene buena performace de read, pero para lo remove y los commit... le cuesta..

Por una mejora es que separes los objetos que tenes repetido en una colleccion y depues los saques.. se entiende

http://wiki.squeak.org/squeak/2985

por otro lado si tenes el strategy en 0 y estas usando un colaborador para la igualación o la detección de duplicados la busqueda va ser bastante pesada, dado que en lugar de los colaboradores vas a tener proxies y cuando accedas magma va ir a buscar las instancias..

Probaste con strategy 1.. el default es 4 pero creo que este caso 1 o 2 es mejor.

Saludos

2010/11/3 Norberto Manzanos <[hidden email]>

Si, use where, un único índice con size 64 (más era terrible). También le pongo como readStrategy depth=0, porque en la mayoría de los casos no es necesario materializar los objetos. La prueba fue que con la estrategia default tardaba mucho más.
Cuando uso Magma, lo que hace es buscar por ese índice y luego hacer una búsqueda dentro de los resultados para hacer comparaciones mas finas. Con 2000 registros el tiempo de agregación era de 2 minutos, el del where de 14 min y la iteración posterior de 4 min.
Ojo, me olvidé de decir que son 4 colecciones Magma.

2010/11/3 Facundo Vozzi <[hidden email]>

Norberto,

para buscar en una MagmaCollection usaste where: y configuraste los indices? Todavía no probé con 76000 registros, voy a probar.

Abrazo

2010/11/3 Norberto Manzanos <[hidden email]>

No, la verdad que no lo probé. Confié demasiado en que esa tarea la haría Magma. Voy a probarlo. Gracias.

2010/11/3 Esteban Lorenzano <[hidden email]>

supongo que algún problema de indices tenés... pero esto que digo es tan una trivialidad que seguro ya lo intentaste: armar un btree ordenado según el índice por el cual buscas los duplicados?

Saludos,

E

El 03/11/2010, a las 4:04p.m., Norberto Manzanos escribió:

Muchachos ( y no tanto) de ClubSmalltalk

Tengo un problema bastante grande y quería ver si alguien me puede dar un consejo.
Tengo una colección de datos en archivos (no es exactamente una base de datos, pero parecido) entre los cuales hay duplicados. Los duplicados no son triviales, hay que hacer algunas cosas para detectarlos, pero ese no es el punto.
Una vez que estos datos estén normalizados pueden persistirse de varias formas, tampoco ese es el problema.
El cuello de botella es la búsqueda en las colecciones. Probé colecciones en memoria, colecciones Magma, Sandstone y el problema es siempre el mismo: el tiempo que tarda la búsqueda. Magma, que fue lo más eficiente, podría llegar a tardar 2 o 3 días para procesar 76000 registros. Un proceso similar, aunque con objetos más complicados, me tardó 2 semanas hace un tiempo. Los de Magma siempre me dicen que algo mal debo estar haciendo, pero nunca aparece que es eso que está mal. No creo estar haciendo nada que pueda hacer que un proceso que debería tardar algunas horas tarde varios días o más.
Estoy a punto de intentar con una base SQL, lo cual me deprime mucho.
¿Alguien conoce algo para Squeak que permita detectar elementos en colecciones en forma más eficiente? ¿Algún truco al menos?

Gracias

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Muchas gracias a todos.
Me da un poco de vergüenza admitir que la solución era simplemente usar Sets.
Me pasa por confiar en herramientas en lugar de pensar simplemente en Smalltalk.
Ya veré si uso Magma o no. SandStone me pareció tentador. Alguien lo uso?

Saludos

--
Norberto Manzanos
Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS)
FaHCE/UNLP - CONICET
Calle 48 e/ 6 y 7 s/Nº - 8º piso - oficina 803
Tel: +54-221-4230125 interno 262

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org