Building Memory-efficient Java Applications • Hacker News Board

NSMeta wrote: post #6

This is probably an 'apple and oranges' type of question, but I haven't used Erlang, nor Java to build large applications. Does anyone know how Erlang compares to Java in regards to memory usage/performance?

using their official docs

http://erlang.org/doc/efficiency_guide/advanced.html#9

(I haven't tried this:

    erts_debug:flat_size(dict:new()).

http://stackoverflow.com/questions/1964015/erlang-what-is-mo...

Re: Building Memory-efficient Java Applications

#14

Post by dasmoth » Thu, Feb 02, 2012, 3:31 PM UTC

Some (not all) of these cases would be helped massively if the JVM gained an equivalent of the fixnum/flonum types from the LISP world. This has been proposed kind-of seriously in the past, e.g.:

http://blogs.oracle.com/jrose/entry/fixnums_in_the_vm

Has anyone seen anything more recent?

Re: Building Memory-efficient Java Applications

#15

Post by joshhart » Thu, Feb 02, 2012, 5:44 PM UTC

For those of you who may not be familiar with them, using http://fastutil.dsi.unimi.it/ collections instead of Java collections is essentially the work-around for most things you'll use. Fastutil has custom classes that remove the pointer overhead associated with storing primitives. Unfortunately, Java really falls apart at the primitives aren't objects thing when it comes to performance.

Re: Building Memory-efficient Java Applications

#16

Post by NSMeta » Thu, Feb 02, 2012, 6:17 PM UTC

jamii wrote: post #10

NSMeta wrote: post #6

This is probably an 'apple and oranges' type of question, but I haven't used Erlang, nor Java to build large applications. Does anyone know how Erlang compares to Java in regards to memory usage/performance?

Per object overhead in functional languages is usually lower since polymorphism is handled at the function level rather than the data level. You don't have to store class pointers etc, just the raw data and probably a type tag. I can't find a reference for erlang's representation but I believe it has only a little more overhead than ocaml which is described here - http://rwmj.wordpress.com/2009/08/04/ocaml-internals/

I know I should thank you by up voting. But also, just want to say that the guide was a very interesting and insightful read.