Managing TOL Memory Usage

[Pedro Gea]

Concretamente en el uso de la herramienta MMS, pero también en otros tareas, procesos o proyectos pesados aparecen problemas de memoria por su excesivo consumo.

Soy consciente que quizá gestionar estos problemas no es fácil y no hay una solución definitiva, pero se sugiere poder disponer de algunos mecanismos que permitan facilitar estas tareas como:

• Conocer el uso de memoria RAM que utiliza TOL
• Generar algún tipo de errores o advertencias cuando el uso de memoria sea de un cierto tamaño crítico
• Conocer el espacio en memoria que ocupa un determinado objeto TOL
• Conocer el número de objetos en memoria de cada tipo

u otras que pudieran sugerirse.

[Víctor de Buen Remiro]

Conocer el número de objetos de cada tipo no ofrece ninguna dificultad de implementación.

Otro tema es el espacio de memoria consumido por un determinado objeto, que es fácil de determinar para algunos tipos de objetos y muy dificil o prácticamente imposible para otros.

Para los objetos virtuales como Code, TimeSet y Series el espacio de memoria incluye un árbol semántico de objetos que no resulta nada sencillo de calibrar. En ESet y Serie hay un espacio adicional de caché de datos. Algunas series finitas pueden perder el árbol semántico y quedarse sólo con los datos.

Para los tipos básicos Real, Text, Date, etc.; resulta en general sencillo determinar el tamaño pero hay que asegurarse de que se hayan desecho de su árbol semántico. Esto debería ser siempre pero no se ha hecho una diagnosis que lo demuestre y pueden quedar restos del pasado hiper-lazy de TOL.

Para NameBlock y Set, habría dos posibles definiciones de tamaño a considerar:

1. contando el tamaño de los elementos contenidos de forma recursiva.
2. contando sólo lo que define el contenedor pero no el contenido.

Si cuentas el tamaño de forma recursiva, entonces cuando un elemento pertenece a dos o más conjuntos lo contarías varias veces; y además el tiempo de cálculo puede ser prohibitivo en conjuntos grandes y profundos e incluso infinito si hubiera referencias circulares. Es decir, sólo tiene sentido la segunda opción: considerar sólo el tamaño del continente.

Aunque fueramos capaces de evaluar el total de memoria ocupada por todos los elementos de un cada tipo, lo cual llevaría un tiempo de cálculo considerable, se tendría sólo una cota de la memoria consumida por los objetos TOL. Eso no es toda la memoria consumida por el proceso, ya que hay otras cosas como los árboles sintácticos, la propia librería C++, etc.; aunque sí sería el grueso de la misma cuando hay un elevado consumo. En caso de ser factible, que lo dudo, el cálculo seria demasiado pesado como para usarlo como centinela de que está aumentando el consumo de memoria, pues habría que evaluarlo cada poco tiempo.

Otra cosa es que la memoria consumida y la memoria asignada al proceso por el sistema operativo no son la misma cosa. Siempre es mayor o igual la asignada que la consumida pues cuando un proceso reclama un número de bytes el sistema suele redondear al alza para que le dejes en paz un rato y para obrar más eficientemente.

En C no sé de la existencia de ninguna función que me diga cuánta memoria está asignada al proceso activo. MemoryStatus te da información sobre el uso de la memoria asignada en general pero no sabes cuánta usa TOL y cuánta el resto de programas y el propio sistema operativo. Se puede implementar en TOL Si alguien sabe de una función C ó C++ que me lo dé, que seguro que la habrá pero cualquiera lo adivina, entocnes sí se podría usar como centinela del uso de RAM.