4 ms·

Performance regression is a bug and GC has a horrific overhead in the average program. My computer is orders of magnitude faster than it was 15 years ago but it

Performance regression is a bug and GC has a horrific overhead in the average program. My computer is orders of magnitude faster than it was 15 years ago but it spends all of it's time wondering around in the wilderness hunting for memory to free. We could have just told it. > those modern garbage collectors are good enough that those downsides just don't matter. This is not what I see. Every I look at a profile of a program written in a GCed language, most of the time is spent in the garbage collector. I can't recall the last time I looked at a c++ profile where more than 10% of the time spent in new/delete. I have seen 100x speedups by disabling GC. You can't ship that, but it proves there is massive overhead to garbage collection.

lomase 2y ago
I also speed up a function 100 times. It was concatenatign strings inside a loop. I changed it to used StringBuilder instead. I could have disabled the GC to get the same speed up.
macintux 2y ago
> GC has a horrific overhead in the average program It doesn't have to be that way. The BEAM is designed for tiny processes, and GC is cheap.
- toast0 2y ago
  I love Erlang and BEAM, but the reason the GC is (mostly) cheap is because self-referential data structures are impossible, so you can have a very simple and yet still very effective GC. One heap per process also helps immensely. Also, when your process has a giant heap, the GC gets expensive. There's been lots of improvement over the years, but I used to have processes that could usually go through N messages/sec, but if they ever got a backlog, the throughput would drop, and that would tend towards more backlog and even less throughput, and pretty soon it will never catch up. That sometimes happens with other GC systems, but it never feels quite so dire.
pjmlp 2y ago
Depends pretty much on what implementation one is specifically talking about. Just like not all malloc()/free() were born equal, to the point companies did made big bucks selling specialised implementations.

lomase 2y ago

I also speed up a function 100 times. It was concatenatign strings inside a loop. I changed it to used StringBuilder instead. I could have disabled the GC to get the same speed up.

macintux 2y ago

> GC has a horrific overhead in the average program It doesn't have to be that way. The BEAM is designed for tiny processes, and GC is cheap.

toast0 2y ago
I love Erlang and BEAM, but the reason the GC is (mostly) cheap is because self-referential data structures are impossible, so you can have a very simple and yet still very effective GC. One heap per process also helps immensely. Also, when your process has a giant heap, the GC gets expensive. There's been lots of improvement over the years, but I used to have processes that could usually go through N messages/sec, but if they ever got a backlog, the throughput would drop, and that would tend towards more backlog and even less throughput, and pretty soon it will never catch up. That sometimes happens with other GC systems, but it never feels quite so dire.

pjmlp 2y ago

Depends pretty much on what implementation one is specifically talking about. Just like not all malloc()/free() were born equal, to the point companies did made big bucks selling specialised implementations.