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

Lew wrote:

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.

Only CPU overhead, and like I said, this is a simplification.


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.

strlen and strcpy never call malloc. The function strdup does call malloc.


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.

I think you are very confused about memory allocation in Java, it is not
trivial when it exceeds certain limits or exists outside function scope.
Just because you have no control over how Java does this, does not mean it
is something you don't need to know about.

When I change the lines to :
arr[i] = new foo("Test:"+i);
and
size_t cb = snprintf(buffer,sizeof(buffer), "Test:%X", i)+1;

In the Java and C++ code, respectively, I get pretty much the same results:
test@localhost:~/scat$ time ./test
2000000

real 0m1.020s
user 0m0.860s
sys 0m0.092s
test@localhost:~/scat$ time java test
Java heap space
Total object:741838

real 0m19.178s
user 0m16.893s
sys 0m1.728s


.

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)