2012/12/14 SAn <
gringo...@gmail.com>:
> * Algunas páginas tardan mucho en cargar, como 2 o 3 segundos (sin
> contar el tiempo de las iamgenes). Por ejemplo esta pagina:
>
http://bonzo.spiccinini.com.ar:8000/wiki/Lucie_%C5%A0af%C3%A1%C5%99ov%C3%A1
> Estuve profileando y llegue a que el 95% del tiempo se gasta en:
>
> 1 2.962 2.962 2.962 2.962 {method 'seek' of 'bz2.BZ2File' objects}
> 1 0.000 0.000 2.962 2.962
> cdpedia/src/armado/compresor.py:89(get_item)
Buena idea profilear, SAn!
> Esta página siempre tarda mucho en cargar, y en cambio otras páginas
> tardan mucho menos.
Esto es lo esperado con la estructura de bloques que tenemos, que está
pensada para monousuario desde un dispositivo óptico.
Esa estructura está optimizada para incrementar la compresión de las
páginas, a expensas de que cada bloque hay que descomprimirlo desde el
principio hasta encontrar el artículo deseado.
Tres propuestas para arreglar esto:
La más sencilla: reducir la cantidad de artículos por bloque, con lo
que se achica el tamaño de cada bloque, y se acelera este caso de uso.
Como contra, se pierde oportunidad de compresión en cada bloque y el
espacio total usado va a ser un poco más.
Por otro lado, en el caso de uso que me imagino típico, la maestra
dice: "busquen sobre Mesopotamia" y los alumnos van a estar mirando
por más o menos los misma docena de artículos. Como propuesta un
poquito más complicada, propongo guardar cada artículo descomprimido
en un caché en memoria, para que esos tres segundos solo afecten al
primero que lo busca.
Y la más complicada (que podría ser para la próxima versión de
cdpedia), es usar una biblioteca de bz2 que sepa saltar a un offset
determinado de nuestro bloque y empezar a descomprimir desde ahí. Y
guardar en el índice de bloque el comienzo de cada parte comprimida.
(esto lo hacía hace algunos años una wikipedia para iphone hecha en
ruby y c)
saludos,
--
alecu