Rendimiento en colleciones de datos en Java

Hubo una época en el rendimiento de las colecciones de datos, es decir java.util.Collections, era realmente penoso. Blogs, forums y portales de programación predicaban sobre la necesidad de optimizar su funcionamiento y muchos se veían obligados a migrar a terceras librerías para obtener clases que a la hora de iterar no fuesen pasando por todos los objetos null de una lista, o que no doblasen el tamaño cada vez que te pasabas del tamaño de la colección y todas estas cosas.

He estado haciendo una pequeña evaluación de estas librerías para confirmar lo que ya me suponia. Esa época de optimización necesaria ya ha pasado a la historia. Hay que reconocer que el rendimiento de las colecciones de datos tanto en el JDK 5 como en el JDK 6 es ahora muchísimo mejor, y las librerías que en otrora tenían algo que decir han pasado un poco desuso. La verdad, no creo que cuente ningún secreto, pero bueno es uno de estos tipos de test que tienes que hacer, al menos para asegurarte de que no te estas perdiendo algo bueno. Lo cierto es que desde hace varios años ya no se oye a ven los post de los creadores de estas librerías en los foros técnicos, lo que te sugiere que ellos mismos sabes que su trabajo ya ha finalizado.

Una de las librerías que he mirado es GNU Trove pero la verdad es que es no pasé ni siquiera de las primeras pruebas. El problema de esta librería es que no implementa las interfaces estándar como java.util.Map o java.util.Set y te fuerza a atarte a sus propias estructuras de datos. Así que nada, descartada (además cuando evalué oval, que te permite utilizar diferentes implementaciones de colecciones de datos ya vi que el rendimiento no era mejor que el de las clases del JDK).

La siguiente en evaluar fue Javolution que tiene una serie de colecciones de datos. Esa librería es interesante. En algunos tests, como por ejemplo al utilizar listas, el rendimiento puede llegar a ser unas 10 veces mayor que con las clases del JDK, mientras que en otros tests el rendimiento es claramente peor, como por ejemplo usando mapas. El problema de esta librería es que está orientada a pequeños dispositivos en el que operaciones como crear y liberar memoria son caras, y por lo tanto sigue un modelo de programación un poco peculiar. Por ejemplo, hace cosas como crear un pool de entradas que reutiliza para las diferentes colecciones de datos, así si tenemos un mapa en el que estamos continuamente colocando y eliminando objetos en lugar de crear nuevas entradas, se reutilizan las que hay en el pool. Sin duda inteligente, pero este tipo de cosas pueden ser bastante perjudiciales dependiendo de como funcione la aplicación, y en mi opinión sería un error el meterse a utilizar librerías que tienen ese funcionamiento tan peculiar.

Por último está Commons Collections. El rendimiento de esta librería es peor que el del JDK, y además no soporta genéricos lo que es un problema adicional. Aún así, la verdad es que el punto fuerte de esta librería ya no es el rendimiento si no más bien la cantidad de diferentes algoritmos y colecciones que tiene implementados, así que puede ser realmente útil para aprovechar cosas que no haya en el JDK.

En fin, mi conclusión es que ahora mismo no tiene ningún sentido ya el mirar como reemplazar colecciones de datos que vienen en el JDK. Eso era una tarea útil hace
quizás hace cinco años, pero ya no lo es. Sin embargo, hay que agradecerle a toda esta gente que allá por el 2000 ya se preocuparon de comenzar a ponerle las pilas a
los desarrolladores del JDK para que mejoraran el rendimiento. Si no hubiese gente quejándose y desarrollando implementaciones mejores probablemente no tendríamos
ahora unas colecciones de datos decentes.