3 ms·

Are you sure about the short-lived allocations being a problem for the collector? My understanding of modern generational garbage collectors was that they perfo

Are you sure about the short-lived allocations being a problem for the collector? My understanding of modern generational garbage collectors was that they performed quite well with short-lived garbage. Not as well as not creating the garbage in the first place, of course, but not so badly as to be a problem in most cases.

ncmncm 5y ago
"Perform quite well" is always relative to some reference. The oldest trick in the book is comparing to something even slower and saying "see? fast!". GC apologists seek to normalize this behavior. They often succeed, at that. Performing quite well against actually fast things, less often.
- jdlshore 5y ago
  You seem to have an axe to grind. Performance isn’t black and white. Optimizing your memory usage isn’t going to do you a whit of good if you’re constrained by your database queries. Optimizing your DB queries isn’t going to do you any good if you’re constrained by a chatty microservice architecture. Optimizing your UI response time isn’t going to do you any good if you’re already below the threshold of perceived speed. Etc. GC performance on short-lived objects is quite good in enough situations to matter, such that optimizing for it, rather than your application architecture, is likely foolish outside of performance sensitive loops. Time is always limited. Spending your optimization budget on micro-optimizations is short-sighted.
  - ncmncm 5y ago
    Meaningless personal criticisms undermine your argument. Performance problems usually appear in places we prefer they would not, often runtime apparatus we poorly control such as GC. It is always preferable to try to ignore and discount those, as they may be arbitrarily hard to fix, so people do. Yet, actually not depending on such apparatus, where it is the problem, gets you free optimization. Performance doesn't care where it is found or lost. Micro-optimization is foundational; fail there, and there is often little else you can usefully do. The best optimizations are not doing the thing at all. GC is always strictly worse than no memory management. Fixing your chatty microservoices and your under- or over-indexed DB queries may do you no good if you have built in bottlenecks of your own. "Quite good" means nothing except in comparison to something else.
    - nyanpasu64 5y ago
      I want a world without garbage collection. I don't think we can achieve a world without garbage collection while there are codebases based around aliased pointers (which makes lifetime reasoning difficult, and causes enough use-after-frees to make the Linux desktop apps I use unstable, unless you use refcounting) and circular references (which is difficult to refcount). Maybe I'll wait for Rust programmers to rewrite software around tree-based ownership (restrictive but immune to these problems) and ECS/arena indexes (can use-after-free but won't segfault). In the time being, while "spiderweb object graphs" are commonplace, perhaps Nim's memory management (https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html) can give us "non-GC by default, refcounting or GC when necessary". I want it to succeed. I hope it does.
meheleventyone 5y ago
This is true for small amounts of garbage but not for large amounts which is still slow and large is relative to the hardware your user is running on. It’ll also cause a death by a thousand cuts where it’s extremely difficult to dig yourself out of poor performance because the cause runs throughout the program. It’s better to look at cheap short lived collection as a great way to get the thing you’re making working but ultimately something that needs to be cleaned up to be production ready.

ncmncm 5y ago

"Perform quite well" is always relative to some reference. The oldest trick in the book is comparing to something even slower and saying "see? fast!". GC apologists seek to normalize this behavior. They often succeed, at that. Performing quite well against actually fast things, less often.

jdlshore 5y ago
You seem to have an axe to grind. Performance isn’t black and white. Optimizing your memory usage isn’t going to do you a whit of good if you’re constrained by your database queries. Optimizing your DB queries isn’t going to do you any good if you’re constrained by a chatty microservice architecture. Optimizing your UI response time isn’t going to do you any good if you’re already below the threshold of perceived speed. Etc. GC performance on short-lived objects is quite good in enough situations to matter, such that optimizing for it, rather than your application architecture, is likely foolish outside of performance sensitive loops. Time is always limited. Spending your optimization budget on micro-optimizations is short-sighted.
- ncmncm 5y ago
  Meaningless personal criticisms undermine your argument. Performance problems usually appear in places we prefer they would not, often runtime apparatus we poorly control such as GC. It is always preferable to try to ignore and discount those, as they may be arbitrarily hard to fix, so people do. Yet, actually not depending on such apparatus, where it is the problem, gets you free optimization. Performance doesn't care where it is found or lost. Micro-optimization is foundational; fail there, and there is often little else you can usefully do. The best optimizations are not doing the thing at all. GC is always strictly worse than no memory management. Fixing your chatty microservoices and your under- or over-indexed DB queries may do you no good if you have built in bottlenecks of your own. "Quite good" means nothing except in comparison to something else.
  - nyanpasu64 5y ago
    I want a world without garbage collection. I don't think we can achieve a world without garbage collection while there are codebases based around aliased pointers (which makes lifetime reasoning difficult, and causes enough use-after-frees to make the Linux desktop apps I use unstable, unless you use refcounting) and circular references (which is difficult to refcount). Maybe I'll wait for Rust programmers to rewrite software around tree-based ownership (restrictive but immune to these problems) and ECS/arena indexes (can use-after-free but won't segfault). In the time being, while "spiderweb object graphs" are commonplace, perhaps Nim's memory management (https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html) can give us "non-GC by default, refcounting or GC when necessary". I want it to succeed. I hope it does.

meheleventyone 5y ago

This is true for small amounts of garbage but not for large amounts which is still slow and large is relative to the hardware your user is running on. It’ll also cause a death by a thousand cuts where it’s extremely difficult to dig yourself out of poor performance because the cause runs throughout the program. It’s better to look at cheap short lived collection as a great way to get the thing you’re making working but ultimately something that needs to be cleaned up to be production ready.