memset and related things

Walter Bright newshound1 at digitalmars.com
Wed Sep 23 02:02:37 PDT 2009


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!



More information about the Digitalmars-d mailing list