5 ms·

The Java tests should be optimized by making the ArrayList a fixed size. All this resizing of the huge array backing it and the potential final very high amount

The Java tests should be optimized by making the ArrayList a fixed size. All this resizing of the huge array backing it and the potential final very high amount of empty backing array slots probably makes the Java result worse than it could be. I wonder if the parallel stream API with a virtual thread pool would make it better or worse.

tialaramex 3y ago
The ArrayList is just a growable array and is presumably using an exponential growth strategy so it's equivalent to what several of the others are doing. You could indeed tell Java how big the ArrayList will grow in advance, but you could for example likewise do that with the Rust Vec by asking for Vec::with_capacity(num_tasks) instead of Vec::new(). Since this is amortized exponential growth it's likely making negligible difference, although it is good style to tell data structures what you know about their size early. The Go approach doesn't appear to pay this penalty, it's just incrementing a (presumably atomic?) counter, although I have no idea where these tasks actually "live" until they decrement the counter again - but most of the others are likewise using a growable array.
- JB_Dev 3y ago
  It looks like most of the languages are doing the same thing w.r.t using a 'List'-style implementation that re-sizes/copies it's internal buffer when it runs out of space. One thing I wonder though is whether the managed languages pay a bigger penalty on the memory usage than the unmanaged languages due to this. In the unmanaged languages, those intermediate buffers should be freed immediately during the re-size operation. But in the managed languages, they might stick around until the next GC. So the peak memory would be higher. In this example the runtime overhead is going to represent more of the memory usage anyway but it quickly isn't negligible. E.g. a list of size 1M is going to be ~8MB (64 bit addresses). So even if the array is re-sized from 1->2->4->8->...->~500K, the end result is not going to be worse than 2X the size.
tester756 3y ago
C#'s list works the same way
pkolaczk 3y ago
Then this should be applied to all benchmarks not just Java.
- Traubenfuchs 3y ago
  Ideally it's a git(hub) repository and people can add PRs to improve the outcome of their favorite languages.

tialaramex 3y ago

The ArrayList is just a growable array and is presumably using an exponential growth strategy so it's equivalent to what several of the others are doing. You could indeed tell Java how big the ArrayList will grow in advance, but you could for example likewise do that with the Rust Vec by asking for Vec::with_capacity(num_tasks) instead of Vec::new(). Since this is amortized exponential growth it's likely making negligible difference, although it is good style to tell data structures what you know about their size early. The Go approach doesn't appear to pay this penalty, it's just incrementing a (presumably atomic?) counter, although I have no idea where these tasks actually "live" until they decrement the counter again - but most of the others are likewise using a growable array.

JB_Dev 3y ago
It looks like most of the languages are doing the same thing w.r.t using a 'List'-style implementation that re-sizes/copies it's internal buffer when it runs out of space. One thing I wonder though is whether the managed languages pay a bigger penalty on the memory usage than the unmanaged languages due to this. In the unmanaged languages, those intermediate buffers should be freed immediately during the re-size operation. But in the managed languages, they might stick around until the next GC. So the peak memory would be higher. In this example the runtime overhead is going to represent more of the memory usage anyway but it quickly isn't negligible. E.g. a list of size 1M is going to be ~8MB (64 bit addresses). So even if the array is re-sized from 1->2->4->8->...->~500K, the end result is not going to be worse than 2X the size.

tester756 3y ago

C#'s list works the same way

pkolaczk 3y ago

Then this should be applied to all benchmarks not just Java.

Traubenfuchs 3y ago
Ideally it's a git(hub) repository and people can add PRs to improve the outcome of their favorite languages.