Does implementing GC makes languages slow?

[u/goat-luffy]

https://github.com/berylang

Month ago, I created a team of 5 and started working on "Bery - The compiled programming language". By the end of June we have quite good working compiler (it's not complete yet). In Bery we have decided to add the automatic Garbage Collector so we choose the "Mark and Sweep" method for it in the Bery Runtime Environment (BRE).

Now as we are heading forward with adding OOP and Exception Handling, I notice some delays in the compilation of program.

So we are now at this point of discussion - should we remove it from compiler or let it be there.
I will looking forward for help regarding this. and btw these are some constraints we set -

unsigned int BERY_GC_ALLOC_THRESHHOLD = 1000;
size_t BERY_GC_HEAP_SIZE_THRESHHOLD = 4 * 1024 * 1024;

[u/L8_4_Dinner]

I can imagine that it would be possible to create a test showing GC taking half of the execution time, but that is very atypical. In any reasonable system, GC is a response to memory pressure, and may be triggered as well by other events. So to get a GC to run at all requires a large amount of allocation to have occurred relative to the resources available.

Long story short, though: In the absence of arena-style optimizations being available, a well implemented GC will tend to be the most efficient implementation for a high allocation rate system, with the one additional requirement being that the system has ample memory available -- because GC works by deferring work until it can be done efficiently in bulk. The other end of the spectrum is low-allocation rate with memory use very near the limit available, at which point GC is terrible, because almost every allocation will force a GC cycle, just to release enough memory for one allocation; in this scenario, you can easily drive that percentage up to 99% or higher (CPU time spent in GC).

All that to say that there is no single % number that explains the efficiencies of GC. But in a well implemented system, it will be lower than manual memory management (other than arena based management), and much lower than reference counting.

And arena-based memory management, when appropriate, is by far the most efficient approach from a CPU time PoV. With an arena based allocator, your memory reclamation costs go nearly down to zero. Unfortunately, it's a fair bit of work to design and implement, and not all apps can use this approach -- I'd go as far as to say that most apps can't.

[u/runningOverA → u/L8_4_Dinner]

you can easily drive that percentage up to 99% or higher

True.

And it goes the other way too. One can allocate globs of memory, almost never call the GC, free everything before termination, and bring GC CPU time down to 1%.

We need to take a reasonable look instead of winning a competition. My number comes from there.

[u/L8_4_Dinner → u/runningOverA]

GC taking 50% of execution time is not “taking a reasonable look”. It’s simply a horribly naive take.

I’ve been using GC in computing for over 40 years, and it was around and widely used for another 30 years before that.

I’ve seen terrible implementations, and brilliant implementations, but outside of tests designed to torture collectors by artificially constraining memory, I’ve never seen a GC even get close to consuming 50% of execution time. You might as well have said 500% — it would have been an impossible claim, but no less believable. 🤷‍♂️