El 29/09/10 16:24, Francesc Alted escribió:
Hola Francesc!
Si, probablemente es eso lo que le pasa a Angel. De todas maneras, usar
el malloc 'a pelo' no hace falta. Mejor usa algo más independiente de
platforma, como `ctypes.create_string_buffer`:
He estado haciendo pruebas con 'create_string_buffer' de ctypes y creo
que no me va a servir.
En primer lugar, 'create_string_buffer' tiene que inicializar la
memoria, algo así como hacer un malloc + memset, algo que lo hace muy
muy lento. Estamos hablando de ejecutar el script en unos pocos
milisegundos en la versión malloc + free, frente a necesitar cerca de un
minuto con 'create_string_buffer' para apenas llenar 512MB de memoria
(solamente RAM, si tuviera swap el método sería todavía mas lento).
Además, el buffer creado con 'create_string_buffer' realmente ocupa el
doble de memoria especificada, ejemplo:
(..)
231 MB
Traceback (most recent call last):
File "./malloc.py", line 23, in <module>
p = ctypes.create_string_buffer(int(n * 1024 * 1024))
File "/usr/lib/python2.6/ctypes/__init__.py", line 66, in
create_string_buffer
buf = buftype()
MemoryError
real 0m48.889s
user 0m13.969s
sys 0m33.198s
En este caso, se han necesitado 48 segundos con la versión
'create_string_buffer' para alcanzar el límite de 231MB, y la misma
versión del script con malloc + free se ejecuta en 0m0.033s para
localizar el límite de 462MB, justamente el *doble* y el tamaño real de
la memoria disponible :(
Sigo investigando, pero por ahora lo mas lógico parece seguir utilizando
las funciones malloc() y free() vía ctypes y encontrar una solución para
x86_64, o bien utilizar 'create_string_buffer' y conocer exactamente el
tamaño en memoria del buffer ocupado. Aún así es un método muy lento,
por si alguien lo quiere probar lo dejo disponible en:
http://pastebin.com/DvFP4hc9
Saludos!
--
Santi Saez
http://woop.es
_______________________________________________
Python-es mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
