Quelle est la performance de Clojure en matière d'empreinte mémoire?

Question

En ce qui concerne l'arrière-plan, j'écris un service web dans Clojure (en utilisant Compojure dans ce cas). Je ne suis pas inquiet au sujet des performances, cela semble être assez bon et je peux toujours tirer plus d'instances de serveur.

Même si une implémentation de Clojure serait 2 à 10 fois plus lente que l'implémentation Java correspondante, je préférerais toujours un code plus propre avant les performances brutes. Bien sûr, cela dépend de ce que vous faites, mais j'aimerais savoir si vous avez des expériences en temps réel en ce qui concerne l'empreinte mémoire de n'importe quel type de solutions serveur de longue durée dans Java vs Clojure?

Answer 1

J'ai un serveur Web basé sur Compojure actif qui fonctionne depuis plus de quatre mois sans aucun accroc (c'est-à-dire sans OutOfMemoryExceptions ou quelque chose comme ça ....). Donc, Clojure semble assez robuste dans les applications de serveur à long terme.

Le serveur Web fonctionne sur Amazon EC2 avec un env. Empreinte mémoire de 230mb. Il est vrai que Clojure est relativement affamé de mémoire - en plus de la surcharge JVM habituelle, il fait beaucoup de choses comme la génération de classe dynamique en arrière-plan qui consomme de la mémoire. Il génère également beaucoup d'objets temporaires (par exemple, la construction d'objets de séquence) et s'appuie sur le GC pour éclaircir les choses. Ceci est en fait une décision de conception dans Clojure - puisque la mémoire est bon marché et la collecte des ordures moderne fonctionne très bien, Clojure a tendance à allouer assez de mémoire de manière assez libérale afin de maximiser la flexibilité et la performance.

Answer 2

Un autre problème est un défaut de conception simple dans la JVM: il utilise UTF-16 comme codage de chaîne interne, donc dans un jeu de données centré sur l'Amérique toutes les chaînes prennent deux fois plus de mémoire qu'elles le devraient.