5 ms·
Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and e
by notriddle 9y ago
Three things:
* Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves.
* Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code.
* A tracing garbage collector needs about five times as much memory as explicit freeing to reach the same performance. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Disadvantages https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
* Like vegetarians, Rustaceans pay more attention to efficiency as a whole. This may give the appearance of Rust being more efficient, even if it's actually not.
- Royalaid 9y agoAdditionally things like Spring and dropwizard also add some overhead for better developer UX which rust doesn't have yet.
- cjalmeida 9y agoSpring is the new EJB. It's bloated and always amazes me on how complex it can get when you need to implement something not provided by Spring itself. With Java 9 modularity and lightweight libraries like Guice you can get much nimbler apps.
- kazagistar 9y agoDagger is a more efficient, simple, debuggable design for DI, and I fully expect to see similar compile time code gen DI in Rust soon. (Adding ownership, mutability tracing, possible stack allocation, etc does make things a bit harder to get right in this arena.)
- vvanders 9y ago> Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. Just a small nit but the term you're looking for here is "value types". Rust does heap allocations(with the pointer overhead) via Box<T>, you just get explicit control over the overhead and cost.
- naasking 9y ago5 times the memory is a serious exaggeration. At least twice, but no more than 3x.
- pnkfelix 9y agoThe linked Wikipedia page references a OOPSLA 2005 paper by Matthew Hertz and Emery D. Berger that presents data saying that with 3x memory you might reasonably expect a 17% slowdown when compared to manual memory management. (And 70% slowdown when limited to 2x memory.) Of course there have been some advanced in GC technology since 2005 (and that paper was deliberately measuring a relatively standard generational approach). But I don’t think I’d call the 5x figure a serious exaggeration.
- naasking 9y agoYes I've read the paper. Advances in CPU microarchitecture alone have noticeably shrunk that gap. There have also been significant algorithmic advances in GC. For instance, a few simple prefetching hints speed up marking easily by 30%, and parallel marking scales almost linearly with core count, to mention but two simple performance improvements. So like I said, maybe in 2005 a 3x memory overhead only incurred 17% slowdown, but 3x overhead is at least at par, and possibly even a little ahead, of manual memory management.
- quotheth 9y agoNone of these are likely the reason - it should be as simple as Java's own managed heap preallocating that space.
- imtringued 9y agoThe first three are not the deciding factors. Other platforms are still 10-100x more memory efficient even though they share the same disadvantages as the JVM. Your fourth point is the primary reason. The GC in the JVM is set to try to waste as much RAM as possible. If you tune the GC you can get a big improvement and the standard Java Frameworks are bloated and slow as hell. In my opinion it's a platform that is bad by default and simply isn't worth using but companies don't care and just buy more RAM.