4 ms·

That's fair, so long as all of your requests have similar allocation profiles. I work on a service which has requests of variable complexity ranging from basica

by Xorlev 10y ago

That's fair, so long as all of your requests have similar allocation profiles. I work on a service which has requests of variable complexity ranging from basically free (10s of KBs) to 10s-100s of MB of allocation. G1GC with a low pause target eliminated a lot of the tuning necessary I'll admit. This could also be a "grass is greener" mentality, but I do believe that in return for the upfront development effort of managing memory as you go vs. deferring to GC leads to more predictable results. Of course, if your algorithms suck, nothing will save you. :P

Thaxll 10y ago
And when you start managing memory you will discover that GC are more powerful than you thought because your simple memory allocator cannot beat 20+years of engineering in the JVM.
- mmstick 10y ago
  Rust's allocation strategy beats the JVM hands down in every benchmark. 20+ years of engineering cannot cover the flaws of VM and GC languages. Writing efficient stack-allocated software will always trump GC/VM solutions.
- zzzcpan 10y ago
  No, nothing can beat manual memory management in performance. GCs don't have a clue where and when they should make what trade offs, but programmers do.
  - kibwen 10y ago
    GC can surpass the performance of manual memory management in certain situations, assuming that the manually managed code is forced to allocate for some reason. GCs almost universally use far more memory than manual schemes, though (I'm having a hard time imagining a counterexample).
    - mmstick 10y ago
      That depends on the allocator you are using. Rust bundles jemalloc by default, which organizes deallocations/allocations such that they are very efficient.
  - jondot 10y ago
    You mean a select few programmers do. And even if you've struck gold and all of your programmers are from the 90's so that they know what it means to manage memory manually, the landscape - the code - always changes and so will the trade off. The deal is that you want to deliver software quickly and make sure it performs adequately, but no one needs perfectly, in regular business.
    - josephg 10y ago
      It really depends on what sort of business you're in. If you're doing application development then UI performance is usually good enough using modern runtime environments and libraries. When this is true being able to release features quickly is the most important metric. But if you're working on a 3d game engine, writing a web browser, writing code on an embedded platform or writing a database then performance itself is a feature. Being lazy with allocation or your choice of algorithms is a really expensive mistake that will hurt your bottom line.
- vvanders 10y ago
  If I know my allocation patterns I can guarantee my arena/fixed block allocator will beat the JVM, every time. Nothing is absolute, there are always tradeoffs. If everything was a one-size-fits-all solution then Software Engineering wouldn't exist as a career.
- jblow 10y ago
  GC enthusiasts say this, but I have never seen it actually be true. The reason is that whoever wrote the GC for your language has to solve an extremely general problem for an extremely large body of users with very different use-cases. A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do. General-purpose GCs are like the F-35 or Space Shuttle ... due to the broad nature of demands they are very complicated, and are much more expensive and perform more poorly compared to specific solutions.
  - wiz21c 10y ago
    >>> A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do. I don't like to sound rhetorical, but writing a memory management system for anything non trivial (that is, a scenario where you allocate and deallocate memory) quickly becomes a difficult problem. Besides, could you give us an example ? I'd like to know about it. My example is a video game where we were allocating thousands and thousands of small stuff and deallocating it. Soon you end up with a fragmented memory where you can't allocate big chunk of memory...
    - vvanders 10y ago
      That's almost the canonical example. Say for a particle system you use a fixed-block allocator that's the size of your particles. Now your allocations are quick since you don't have to do fitting and you don't fragment memory since they're all clumped together. Other common trick in video games is to have a single-frame arena allocator for objects that are transient frame to frame. You just move a pointer forward and reset the pointer at the end of the frame.
    - aschampion 10y ago
      That's an odd example, given most video games are written in memory managed languages for performance reasons. Typically an allocation pool would be used for that case because there's some bound to the number of simultaneously allocated objects and each object has a homogeneous memory footprint. It's also odd because you're replying to a well-known game designer. That said, there are allocation-heavy workloads for which GC is well suited.

by Xorlev 10y ago

Thaxll 10y ago

And when you start managing memory you will discover that GC are more powerful than you thought because your simple memory allocator cannot beat 20+years of engineering in the JVM.

mmstick 10y ago
Rust's allocation strategy beats the JVM hands down in every benchmark. 20+ years of engineering cannot cover the flaws of VM and GC languages. Writing efficient stack-allocated software will always trump GC/VM solutions.
zzzcpan 10y ago
No, nothing can beat manual memory management in performance. GCs don't have a clue where and when they should make what trade offs, but programmers do.
- kibwen 10y ago
  GC can surpass the performance of manual memory management in certain situations, assuming that the manually managed code is forced to allocate for some reason. GCs almost universally use far more memory than manual schemes, though (I'm having a hard time imagining a counterexample).
  - mmstick 10y ago
    That depends on the allocator you are using. Rust bundles jemalloc by default, which organizes deallocations/allocations such that they are very efficient.
- jondot 10y ago
  You mean a select few programmers do. And even if you've struck gold and all of your programmers are from the 90's so that they know what it means to manage memory manually, the landscape - the code - always changes and so will the trade off. The deal is that you want to deliver software quickly and make sure it performs adequately, but no one needs perfectly, in regular business.
  - josephg 10y ago
    It really depends on what sort of business you're in. If you're doing application development then UI performance is usually good enough using modern runtime environments and libraries. When this is true being able to release features quickly is the most important metric. But if you're working on a 3d game engine, writing a web browser, writing code on an embedded platform or writing a database then performance itself is a feature. Being lazy with allocation or your choice of algorithms is a really expensive mistake that will hurt your bottom line.
vvanders 10y ago
If I know my allocation patterns I can guarantee my arena/fixed block allocator will beat the JVM, every time. Nothing is absolute, there are always tradeoffs. If everything was a one-size-fits-all solution then Software Engineering wouldn't exist as a career.
jblow 10y ago
GC enthusiasts say this, but I have never seen it actually be true. The reason is that whoever wrote the GC for your language has to solve an extremely general problem for an extremely large body of users with very different use-cases. A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do. General-purpose GCs are like the F-35 or Space Shuttle ... due to the broad nature of demands they are very complicated, and are much more expensive and perform more poorly compared to specific solutions.
- wiz21c 10y ago
  >>> A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do. I don't like to sound rhetorical, but writing a memory management system for anything non trivial (that is, a scenario where you allocate and deallocate memory) quickly becomes a difficult problem. Besides, could you give us an example ? I'd like to know about it. My example is a video game where we were allocating thousands and thousands of small stuff and deallocating it. Soon you end up with a fragmented memory where you can't allocate big chunk of memory...
  - vvanders 10y ago
    That's almost the canonical example. Say for a particle system you use a fixed-block allocator that's the size of your particles. Now your allocations are quick since you don't have to do fitting and you don't fragment memory since they're all clumped together. Other common trick in video games is to have a single-frame arena allocator for objects that are transient frame to frame. You just move a pointer forward and reset the pointer at the end of the frame.
  - aschampion 10y ago
    That's an odd example, given most video games are written in memory managed languages for performance reasons. Typically an allocation pool would be used for that case because there's some bound to the number of simultaneously allocated objects and each object has a homogeneous memory footprint. It's also odd because you're replying to a well-known game designer. That said, there are allocation-heavy workloads for which GC is well suited.