RssNo, no me refiero a los abnegados funcionarios que se esfuerzan por mantener limpias nuestras calles. Me refiero a ciertos mecanismos que disponen algunas implementaciones de ciertos lenguajes tales como JavaScript, Objective C, Java, etc.
Básicamente, el recolector de memoria hace un seguimiento de la memoria utilizada, y se encarga de ir liberando aquella que ya no se usa. No me voy a meter en una explicación técnica, porque no es el lugar; baste con decir que con un recolector de basuras se libera al programador de la tarea de indicar cuándo liberarla (valga la redundante redundancia de liberar la liberación). Y esto es bueno, o eso me han dicho.
Ahora bien, llevo unos cuantos años trabajando en una aplicación web para unos clientes de la empresa en la que trabajo. Es un programa bastante complejo, concretamente un administrador de pedidos con facturación, el cual está escrito en PHP y JavaScript1. Cuando el proyecto ya alcanzó cierto nivel adquirió como característica que, tras un par de horas de trabajo con el mismo, sufría un decaimiento general en el rendimiento, tardando cada vez más en realizar las operaciones hasta ser prácticamente inutilizable (el programa es usado por el operador durante toda la jornada).
Cuando tuve la oportunidad de estudiar este problema, algo que mis colegas españoles saben que es harto difícil de tener, me di cuenta de que todo el problema estaba en el lado cliente, ya que las consultas al servidor eran suficientemente rápidas. Aparte de la sobrecarga del microprocesador, la memoria iba creciendo sin descanso a cada operación realizada. Consulté por aquí y por allá sobre la gestión de memoria en JavaScript, pero en el mejor de los casos se limitaban a venderme lo maravilloso que es tener un recolector de basuras.
Hasta que se me ocurrió que si en este lenguaje hay un new, quizá también hay un delete. Y resulta que así era. En ese momento se me terminó el tiempo que podía perder (sic) en el problema, pero cada vez que tenía que hacer alguna modificación al programa procuraba buscar por los alrededores por si encontraba un buen lugar donde colocar un delete. En cuanto hube colocado estratégicamente un puñado de ellos, la tendencia del programa a reducir su rendimiento dejó de ser tan patente, llegando a ser utilizable aun tras toda la jornada, y últimamente apenas se observa una reducción de velocidad, salvo si realizas ciertas funciones que no tengo muy claras. Ahora los problemas que más me preocupan son otros.
Tras esta experiencia, la escasa confianza que ya tenía en estos cachibaches se ha esfumado por completo. No sólo no voy a volver a confiar de nuevo en ellos, sino que voy a recomendar a diestro y siniestro que no los use nadie. Y a ello voy:
Destruid los objetos en cuanto no los necesitéis. Evitad confiar en el colector de basura. Si el lenguaje no lo implementa, ni se os ocurra instalar o crear una biblioteca para añadírselo (sí, Objective C, estoy hablando de tí). Y si estáis diseñando un nuevo lenguaje de programación, por favor: no lo hagáis.
Y ya está.
1Para que conste en acta, ya dije cuando me lo propusieron que, en mi opinión, no eran los lenguajes ni la plataforma más acertada para este programa, pero maldito el caso que me hicieron.
