4 ms·
It's because Rust frees memory at the moment it's not needed while Java runtime maintains a pool of memory and does garbage collection every now and then. This
by oriolid 5y ago
It's because Rust frees memory at the moment it's not needed while Java runtime maintains a pool of memory and does garbage collection every now and then. This is a huge performance boost for code that does a lot of small allocations, and if you want to play dirty, reserving a large enough heap may allow you to run through a benchmark without a single garbage collection.
Seriously, every now and then there's a story about some fintech company who use Java and use large enough heap that there's no garbage collection during stock market opening hours.
- mysterydip 5y agoInteresting, makes sense. So presumably if you ran the benchmark over a long enough time, performance would take a dive while the gc did its thing.
- oriolid 5y agoPossibly. I haven't tried running this benchmark with different heap sizes, but to me the 99% latency looks like it doesn't try to avoid GC. The JVM is really fast at memory management.
- kaba0 5y agoDuring the benchmark's duration, the GC was definitely ran. Java simply has really advanced GCs.
- steveklabnik 5y agoRust can do that but it also can not do that. You’d want to not do that here. That is, this is a library concern, not really a language one.