Tal vez me estoy yendo de tema, pero en un sistema que hice para procesar muchos datos terminé aplicando flyweights a cosas que no esperaba, como numeros, fechas o nombres. Por ejemplo, si tengo una colección con 1 millon de "Facturas del mes", entonces la cantidad de fechas posibles son 30 y no 1 millón. Y está claro que tener 30 fechas es mas barato en términos de memoria y de muchas operaciones (y a veces mas caro de instanciar al principio). Viniendo de un pasado de bases de datos relacionales, siempre tendía a "factorizar" lo obvio, cosas como Ciudad, Cliente, Género, Tipo, etc.. Pero nunca pensé que el importe de una factura , la fecha o un "campo string" debían factorizarse. Pero en Smalltalk resulta muy natural hacerlo y darse cuenta que tampoco suelen existir 1 millón de importes distintos, ni un millón de nombres distintos, de hecho los nombres de personas son muy pocos. Además en ese tipo de colecciones, los objetos suelen tener mas de una fecha y mas de un variable de instancia de tipos numéricos, por lo que la misma instancia suele vivir en varias partes del objeto. Si me tocara analizar a la población de Argentina, la fechas de nacimiento REALES no serían 40 millones, serían unas 40 mil, o sea mil veces menos objetos. Algo que a veces pasa es que cuando se encuentran muchas repeticiones el tiempo de instanciación de las colecciones también baja mucho porque a la VM le cuesta menos hacer búsquedas que reservar tanta memoria. Para tranformar un objeto en otro que esté siendo usado previamente les mando el mensaje #used, que obviamente me devuelve el objeto del pool para su reemplazo. Todo esto tiene muy bajo costo en términos de diseño y empiezan a aparecer beneficios por donde uno menos lo espera. En mi caso, a clave fue sacarme las reglas de factorización de la cabeza y prestarle mas atención al inspector de Smalltalk.
Diego Coronel On 3 mayo, 14:16, Angel Java Lopez <[email protected]> wrote: > Interesante tema/problema.. > > Por que hay millones de float? Yo me imagino algun calculo, pero igual > luego el garbage collector deberia liberarlos. El problema es la memoria? > se acaba? Se necesitan los millones de floats, digo, que esten > referenciados y no sean liberados por el GC? no habra forma de cambiar el > algoritmo? O el problema es el tiempo (mucho tiempo creando) y no la > memoria? > > 2012/5/3 [email protected] <[email protected]> > > > > > Hola GallegO, > > Supongo que habrás hecho un flyweight y es lo que generalmente me > > sirvió. Tal vez si contarás un poco mas surjan mas ideas, en las cosas > > que me topé terminé por darme cuenta que los números son muchísimos > > menos que los que parecen, en matemática son infinitos pero en la > > compu no, y en la realidad mucho menos. > > > Abrazo > > > Diego > > > On 3 mayo, 13:04, GallegO <[email protected]> wrote: > > > Gente: > > > > Quería saber si alguien se le ocurre de que forma uno puede evitar la > > > instanciación de Float en Dolphin, o si se les ocurren en cualquier > > > Smalltalk en forma transparente. Tengo un problemita con algunos > > > millones de floats. En algunos lados lo puedo solucionar con un > > > lightweight pero cuando se usan primitivas en un calculo estoy al > > > horno. > > > > Gracias por su ayuda :) > > > > Saludos > > > GallegO > > > -- > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > >http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
