> Did you also implement object pooling for the Java variant (commonly used in high perf apps)?
In the specific case I don't think you need to; I've seen generated code (from java sources) simply reuse an object in a tight loop. IOW, it doesn't allocate new memory for the instance within a loop, for each invocation of the loop. The memory for the instance is allocated once and then reused.
(For a small allocation (a small instance) I would expect a smart compiler to not allocate anything and simply create the for-loop instance on the stack).
The optimization you are getting at has not much to do with object size, but subsequent usage. If the object reference escapes, it has to be allocated on the heap. Value semantics could/will help here.
> The optimization you are getting at has not much to do with object size, but subsequent usage.
Size plays a part: it determines whether or not an instance first gets allocated on the heap or the stack[1]. Heap allocation gets expensive in a tight loop.
> If the object reference escapes, it has to be allocated on the heap. Value semantics could/will help here.
The assumption is that we are talking about local-only data objects (not returned or outliving the scope). Forgive (and correct) me if I am under the incorrect assumption.
[1] I'd expect a smart compiler to do this: a data object that requires 1MB should at no point be on the stack, while a data object that requires 32 bytes has no business starting the allocator, causing a context switch to the kernel that faults a new page. The specific thresholds are dependent on the runtime and OS support.
For these sorts of micro-benchmarks you can usually attain interesting results with Java. I once constructed specifically designed to show how the JVM's ability to online and un-inline code could make certain programs much faster than C.
Once I implemented a simple pool allocator in C++, it ran circles around Java.