Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Thu Jul 21 2005 09:27 am

Jon Harrop wrote:
> Rob Thorpe wrote:
> > Objects in Java are heap allocated, no matter what they are.  There are
> > no stack allocated objects as there are in C++.  This means that the
> > heap must take on the roll filled by both the stack and heap in other
> > languages.  This means the garbage-collector must waste time cleaning
> > up stuff that's gone out of scope that in other languages would be
> > dealt with by just moving the stack pointer.
> >
> > This means that compared to other languages with GC Java relies more on
> > it's garbage collector,
>
> No. I believe many other language implementations (e.g. ocamlopt) work in
> the same way but are much faster than Java. I think Java's poor performance
> is due to Java implementations failing to optimise common OO patterns.

Really?
The problems with Java are mostly semantic: everything is an object and
every object must be on the heap.  I'm fairly sure that those who write
JVMs have mastered the art of optimizing them under these limitations.

Java is a very big business, probably many hundreds of programmers
spend their time optimizing JVMs.  OCaml on the other hand is written
by only a handful of people.  I expect that the coders of JVMs have
optimized into the ground the OO patterns they have found to be the
most common.

More likely the semantics and common usage patterns of OCaml make it
easier.

> > and of course it has the extra overhead of GC unlike C++ and C.
>
> GC is often faster than manual allocation and deallocation so it isn't
> really fair to call it an "overhead". Indeed, I'd call manual allocation
> and deallocation an overhead...

It's certainly mental overhead.  I doubt that there would be hardly any
situations where a GC would outperform manual allocation though.

.