3 ms·
Code with lots of small short-lived objects is often by default faster in something like rust, because stack allocation is very efficient (even compared to the
by rcxdude 6y ago
Code with lots of small short-lived objects is often by default faster in something like rust, because stack allocation is very efficient (even compared to the bump allocation in a generational GC, which is much more efficient than heap allocation but worse than stack). If you have a lot of objects which can exist on the stack in your program, java will tend to do poorly in comparison.
(and in general java will trade off memory for speed: modern GCs can be very efficient in execution time but will use 2x-3x as much memory in return. If you want low memory usage your code is going to run slower).
- mratsim 6y agoDoes the borrow checker interfere with memory and object pools implementation? Because if you require heap allocation for many short-lived objects, I expect this would be one of Java strengths unless you use an object pool.
- steveklabnik 6y ago"interfere" is a funny word, but you could do this in Rust. It's not super common, though the related technique of "arenas" can be, depending on domain.