Manual memory management is much more predictable (which is really nice for interactive/real-time programs), it does have nontrivial runtime overhead: malloc and free aren't free (pun slightly intended), and often costlier than a bump allocator most moving/copying GCs use (just increment a pointer and have a very branch-predictable conditional to check OOM). Also, moving/copying GCs increase data locality by bringing live objects closer, which is more cache friendly.
I agree that manual memory management is much more predictable than garbage collection, I just wanted to touch on the nuances of the memory overhead of manual memory management.
Also, if the program creates lots of short-lived objects (which is often the case), a generational garbage collector would be pretty fast because it will reclaim/move a few objects rather than deallocating many objects. An arena collector or allocating on the stack might be better (and manual methods) in this scenario though.
> It will have delays, they may be small, but there is know way to know when they will come.
It was my understanding that C4 doesn't do pauses.
On the face of it, I do not believe it. "Mostly dosen't pauses" is believable. Great strides have been made
But what is it? Where can I find out about it? A deterministic garbage collector would (a) prove me wrong and (b) be a Very Good Thing
Maybe. But not predictably. It will have delays, they may be small, but there is know way to know when they will come. This can be managed but it is all overhead. Manual memory management has none of that run-time overhead (but a tonne of programmer overhead)