Re: C++ vs Java "new" (no flame war please!)

mlw wrote:
That is simply not true on either account, I don't need to "fix" the start
of anything. There is no memory overhead for each class. The "allocation"
overhead time is nothing more than a simple integer addition.

It is that addition to which I refer.

Lew wrote:
Even if one did copy the String, the time overhead of the Java allocation and copy would be much less than for the
C++ code you
showed.

mlw wrote:
How is this possible?

I was referring to your code:
void *foo::new(size_t size, char *string)
{
size_t cbstr = strlen(string)+1;
size_t cb = cbstr + size;
foo * t = (foo *) malloc(cb);
char * name = (char *) &t[1];
strcpy(name, string);
t->m_name = name;
}

strlen() has overhead and strcpy() has overhead.

Well, not seen in the example would be that the string is read from a file
into a local buffer which gets reused.

In Java, it would be read into a new buffer each time, the allocation overhead of which is negligible, and the copy from the file into the buffer would be the only copy. There would not be the copy represented in your code by the strcpy() call. The small overhead of the new buffer allocation is well offset by the savings in the string copy time.

char buffer[MAX_SIZE]

while(!feof(f))
{
if(fgets(buffer, sizeof(buffer), f))
{
new(buffer) foo();
}
}

Where is the allocation overhead that you are referring too?

in the new operator that you wrote, particularly in the strlen() and strcpy() calls, which add to the time and memory footprints.

Java would allocate a new string for each string. My code does not issue any
memory allocation for the string, it comes from a fixed length block and it
is combined with the object proper.

But the Java code would have one less copy of that string, and that would save copy time. The fact that the memory is allocated at new time in Java is about the same as the memory add at new time in your C++ example. A Java object allocation is not much more than a memory limit add.

arr[i] = new foo(Integer.toHexString(i));

size_t cb = snprintf(buffer,sizeof(buffer), "%X", i)+1;

You might be comparing the speed of toHexString() to that of snprintf(), and not allocation times.

You also are not comparing Java with custom allocators to Java without custom allocators. I am not arguing that Java is faster than C++, only that custom allocators in Java would not help the Java performance.

With Java you have the overhead of bytecode interpretation and multiple threads running in the JVM at the same time, plus there is the startup time of the JVM itself that you did not factor out. Consequently you have not measured memory allocation time vs. memory allocation time and we can draw no conclusions about the relative efficiency of the two schemes.

Put your timing loops inside the program, and while you're at it give the Java Hotspot compiler a few hundreds of loops to settle in. Oh, and try java -client vs. java -server. You've got to factor out the overhead of setup and so on before timing comparisons make sense.

-- Lew
.

Relevant Pages

  • Re: forth and virtual memory
    ... too, maybe even the same order, so ordering the blocks by allocation ... on systems with too little memory ... What Java is known for, and what it actually does, are two distinct ... My measurements indicate that some of the benchmarks (from SpecJVM98, ...
    (comp.lang.forth)
  • Re: C++ vs Java "new" (no flame war please!)
    ... of such objects that would fit in available memory. ... memory and much more time than would the JVM for the equivalent Java ... The "allocation" ... If you have a small object with a string, ...
    (comp.lang.java)
  • Re: D gets it right
    ... >releasing memory properly using good old free, ... Java and ... (define (make-adder k) ... stack-based allocation method like that espoused by propoents of RAII, ...
    (comp.programming)
  • Re: OT: C++ overloading operators
    ... use of memory, at the cost of a somewhat slower execution. ... dynamic allocation, no matter how many "clever tricks" are used... ... I don't think you will find many programmers outside the ... "big" number and very generous overhead allocation. ...
    (comp.dsp)
  • Re: forth and virtual memory
    ... filesystem (filesystem allocation heuristics are tuned for low ... in particular in systems with little memory. ... This just states that garbage collection, when properly done, is not ... the Java JIT compiler is somewhat equivalent (on ...
    (comp.lang.forth)