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

Jon Harrop wrote:
> Chris Dollin wrote:
> > Jon Harrop wrote:
> >>> There's unnecessary plumbing, I'll grant; are we talking more than a
> >>> factor of 2 here? Ish?
> >>
> >> I'd expect SML and OCaml to be up to 5x faster than Java.
> >
> > Just for closures, or in general? Deep gloom. I thought they'd got
> > the performance of Java up better than that.
>
> For anything which does lots of allocation and deallocation. MLs are
> typically extremely fast at allocation and deallocation. Not only is Java
> very slow at object allocation and deallocation, it forces you to use
> objects when there are often more appropriate and efficient constructs.
>
> >>> I don't doubt
> >>> that if you make lots of new objects you will do worse than if you
> >>> don't have to create them.
> >>
> >> As Java forces you to use OO,
> >
> > Heap-allocated objects, to be specific, yes?
>
> Yes. I'm not sure it's relevant though, e.g. the OCaml compiler happens to
> heap allocate, the SML may be heap or stack, the C++ is mostly stack and
> all are much faster than Java.
>
> My guess is that C++ does a much better job of optimising simple objects
> (e.g. structs) whereas Java (at least Sun's JDK 1.5) does a very poor job.

The problem is in the semantics of Java and the way JVMs work.

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, and of course it has the extra overhead of GC
unlike C++ and C.

.