views:

230

answers:

2

As for the background, I am writing a web service in Clojure (using Compojure i this case). I am not worried about performance, that seems to be good enough and I can always fire upp more server instances.

Even if a Clojure implementation would be 2-10 times slower than the corresponding Java implementation, I would always prefer a cleaner code before raw performance.

Of course, it depends on what you are doing, but I would like to know if you have any real-live experiences when it comes to memory footprint of any type of long-running server solutions in Java vs Clojure?

+7  A: 

I've had an active Compojure based web server running for over four months without a single hitch (i.e. no OutOfMemoryExceptions or anything like that....). So Clojure seems pretty robust in long running server applications.

The web server is running on Amazon EC2 with an approx. 230mb memory footprint.

It is true that Clojure is relatively memory hungry - in addition to the usual JVM overhead it does a lot of things like dynamic class generation in the background that eat up memory. It also generates a lot of temporary objects (e.g. construction of sequence objects) and relies on the GC to clear things up.

This is actually a design decision in Clojure - since memory is cheap and modern garbage collection performs very well, Clojure tends to allocate memory fairly liberally in order to maximise flexibility and performance.

mikera
Indeed, the class generation can eat up memory. For a long-running and/or heavy process I found it pays to learn a bit about java memory types and garbage collection and learn to tweak JVM parameters.
Greg Harman
+2  A: 

Another problem is a simple design flaw in the JVM: it uses UTF-16 as its internal string encoding, so in an American-centric data set all strings take twice as much memory as they should.

technomancy