language_fan wrote:
I have seen people many times mention that Java is in general orders of
magnitude slower than D, no matter what kind of algorithms you run on
both environments. This is because of the VM - nothing on a VM can run
faster than native code, they say. If you decide to hide the bad results
(for D), it will only reinforce the misinformation. I personally use a
lot of heap memory allocation in my work, and so far Java has not only
been safer (and provides decent stack traces and no compiler bugs), but
also faster - each time.
If you simply time a heap allocation in D and Java, Java will probably
be faster not because of anything inherently faster about Java, but
because Sun has poured billions of dollars into trying to make their
heap allocator faster.
However, a typical D program does far fewer allocations than the Java
equivalent, for the simple reason that D supports stack allocated and
embedded value aggregates while Java requires them to be on the heap. It
is the much reduced need for the heap to be fast that is an advantage for D.
Java does do some escape analysis to try and allocate heap objects on
the stack instead, but I don't know how effective this is, and even that
won't help if you try to embed a value aggregate into a class:
struct S { int x, y, z; }
class C
{
S v; // in Java this would require a second heap allocation
}
In other words, one of the most effective techniques for speeding up
heap allocation costs is to design the data structures so they require
fewer allocations!
