3 ms·

Garbage collection is not slow. Actually it's probably the fastest dynamic allocation method. Allocating data with a copying garbage collector is O(1), which i

Garbage collection is not slow. Actually it's probably the fastest dynamic allocation method. Allocating data with a copying garbage collector is O(1), which is as fast as allocating something on the stack, while malloc() is usually O(log(n)) with n being the number of live objects in the heap. Running a collection on a such GC is usually O(n), with n begin the number of live objects. This is way faster than calling free() on each allocated object, but slower than using the stack. They idea that languages that rely on a garbage collector are slower is not really due to the garbage collector, but to the fact that they allocate way too much on the heap (I'm looking at you, Java). C/C++/Rust are awesome because they allow you to control way more where data is allocated. Also, it's theoretically possible for a compiler in a functional programming language to decide to allocate on the stack instead of the heap. Another issue is that the time is will take to execute the collection can be unpredictable. It can happen that the GC will stop the entire program for a few milliseconds every few seconds. This is highly undesirable for realtime applications such as video-games.

imtringued 10y ago
The only problem with GCs is the stop the world pause. I'm seriously wondering why not more languages have a gc per "process" like erlang.
- nickpsecurity 10y ago
  The only problem with "stop-the-world" GC's on hardware not built for them. There's "pauseless" collectors out there where that either doesn't happen or happens so fast you don't experience it. Some do microseconds. One was in a Scheme machine where they put it into the memory subsystem. So, the program just allocated, deleted, whatever with a parallel, hardware GC managing pages in the background. Many things one can do in GC's. The only one I know with mainstream success is Azul's: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/images/c4_pap... https://www.azul.com/products/zing/ https://www.azul.com/products/zing/ Note: No affiliation with them. Their Azul systems and pauseless GC were simply the best stuff I found researching Java & GC hardware. Assuming they match marketing claims. ;)

imtringued 10y ago

The only problem with GCs is the stop the world pause. I'm seriously wondering why not more languages have a gc per "process" like erlang.

nickpsecurity 10y ago
The only problem with "stop-the-world" GC's on hardware not built for them. There's "pauseless" collectors out there where that either doesn't happen or happens so fast you don't experience it. Some do microseconds. One was in a Scheme machine where they put it into the memory subsystem. So, the program just allocated, deleted, whatever with a parallel, hardware GC managing pages in the background. Many things one can do in GC's. The only one I know with mainstream success is Azul's: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/images/c4_pap... https://www.azul.com/products/zing/ https://www.azul.com/products/zing/ Note: No affiliation with them. Their Azul systems and pauseless GC were simply the best stuff I found researching Java & GC hardware. Assuming they match marketing claims. ;)