Re:Java garbage collection can be really slow
by sievebrain on Saturday April 23, 2016 @01:45PM
(#11556532)
Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimisations benefit your code the most.
Yes you could also pre-allocate, but that's often more awkward than just allocating at the time of need, and besides, Java can turn heap allocations into not only stack allocations, but fully scalarise them (i.e. break down an allocation into a set of local variables and then delete any that are unused, move them around, etc).
Re:Java garbage collection can be really slow
by CyberDildonics on Saturday April 23, 2016 @02:43PM
(#11556799)
> Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimizations benefit your code the most.
This could not possibly be further from the truth. Getting rid of heap allocations can speed something up by ~7x. Cache locality can speed something up by 50x. Compiler optimizations do very little compared to accessing memory in a predictable way.
Re:Java garbage collection can be really slow
by imtringued on Sunday April 24, 2016 @07:35AM
(#11559338)
Indeed! In Java or dynamic langauges you are forced to always use a reference. Which means you'll get cache misses pretty much everywhere.
I thought it was about speed.
> The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left.
The C++ equivalent would be to do heap allocation and never free, then shut the process down which will return its memory to the OS. Heap fragmentation wouldn't matter here since you aren't freeing any memory.
Fundamentally if you can avoid freeing any memory all day then you should just allocate it up front an be done with it. Anything else is ignoring the more fundamental point that you are using a limited amount of memory and pretending that you aren't.