¿Qué tan bien se desempeña Clojure en lo que respecta a la huella de memoria?

Question

En cuanto a los antecedentes, estoy escribiendo un servicio web en Clojure (utilizando Compojure en este caso). No me preocupa el rendimiento, parece ser lo suficientemente bueno y siempre puedo iniciar más instancias de servidor.

Incluso si una implementación de Clojure fuera 2-10 veces más lenta que la implementación de Java correspondiente, siempre preferiría un código más limpio antes del rendimiento en bruto.

Por supuesto, depende de lo que esté haciendo, pero me gustaría saber si tiene alguna experiencia real en lo que respecta a la memoria de cualquier tipo de soluciones de servidor de larga duración en Java vs Clojure.

Answer 1

He tenido un servidor web activo basado en Compojure ejecutándose durante más de cuatro meses sin un solo enganche (es decir, no hay OutOfMemoryExceptions ni nada de eso ...). Así que Clojure parece bastante robusto en aplicaciones de servidor de larga ejecución.

El servidor web se ejecuta en Amazon EC2 con una capacidad de aprox. 230mb de huella de memoria.

Es cierto que Clojure está relativamente hambriento de memoria: además de la sobrecarga de JVM habitual, hace muchas cosas como la generación dinámica de clases en el fondo que consume memoria. También genera una gran cantidad de objetos temporales (por ejemplo, la construcción de objetos de secuencia) y se basa en el GC para aclarar las cosas.

Esto es realmente una decisión de diseño en Clojure, ya que la memoria es barata y la recolección de basura moderna funciona muy bien, Clojure tiende a asignar memoria bastante liberalmente para maximizar la flexibilidad y el rendimiento.

Answer 2

Otro problema es un error de diseño simple en la JVM: usa UTF-16 como su codificación de cadena interna, por lo que en un conjunto de datos centrado en Estados Unidos todas las cadenas requieren el doble de memoria que deberían.