Análisis del consumo de memoria de Eclipse

Markus Kohler ha publicado en su blog el resultado de un análisis del consumo de memoria de Eclipse usando la herramienta Eclipse Memory Analyzer (MAT) de la cual es comitter. Esta herramienta es un plugin que analiza los heap dumps generados por la JVM, en específico aquellos con el formato HPROF. Formato soportado por la JVM de Sun, de HP y SAP (no se menciona si BEA JRockit lo soporta).

El análisis se realizó usando la JDK 1.6_10 y Eclipse 3.4 M7 con el proyecto de Winstone cargado. Los resultados son muy interesantes. Como podrás ver en el post de Markus en el resumen del análisis se aprecia que el corrector ortográfico es el objeto que ocupa más memoria memoria del IDE: 5,6 Mbyte lo que equivale a casi el 25% del total de 22,7 Mbytes ocupados por Eclipse. Este corrector ortográfico se incluye desde Eclipse 3.3 (Europa) y para mi es una de las características más molestas del IDE: sólo tiene soporte para Inglés y lo último que necesito es que mi IDE me diga si escribí bien o mal un comentario y además me lo marqué en rojo. Además de que siempre está activado por defecto.

La siguiente sorpresa viene cuando Markus decidió ver porqué esta herramienta ocupa tanta memoria y la respuesta es toda una sorpresa: el corrector está implementado como un enorme HashMap que hace un map de un String a una lista de Strings. Markus planea poner un bug sobre este tema, esperemos que lo hayan arreglado para cuando Eclipse 3.4 sea publicado.

El segundo punto que revisa es lo que llama su truco favorito para análisis de consumo de memoria: buscar Strings duplicados. Eclipse MAT tiene una herramienta que le ayudó en este trabajo y con la cual pudo detectar que los objetos String ocupan 12Mbytes del total de 22,7; de esos 4 son ocupados por el corrector ortográfico. Al hacer unh group by de los Strings, Markus pudo detectar los duplicados que muestran que Strings como "id" están duplicados 1988 veces o "name" 1210. El siguiente paso fue ver que clases eran la responsables de estas duplicaciones y encontró que ConfigurationElement es la clase responsable por mucho de la mayor cantidad con 13242.

Como dice Markus, que existan tantos Strings duplicados en una aplicación es el mayor problema de desempeño presente en la mayoría de las aplicaciones Java, esta herramienta nos permite detectarlo e incluso nos determina las clases responsables.

En mi experiencia este tipo de análisis en el mejor de los casos sólo se hacen cuando las cosas empiezan a fallar con típicos OutOfMemory y una vez que el desarrollo ha terminado. Markus nos demuestra en este artículo como de una forma bastante sencilla fue posible detectar dos objetos que consumen una cantidad de memoria importante (la implementación del corrector ortográfico y los Strings duplicados de la clase ConfigurationElement) que de arreglarse tendrían un impacto bastante bueno en el consumo de memoria de Eclipse. Con este tipo de herramientas ya no hay excusas para dejar estos análisis hasta que los errores empiecen a surgir.

Por cierto, Markus tiene planeado realizar el mismo análisis de Netbeans así que no está de más revisar su blog para cuando lo publique.