Tracing GC is not always faster. GC time is proportional to the size of the allocated memory, reference counting time is not.
You can get a "stop the world" effect with a cascade set of references reaching zero.
The actual garbage collection in all collectors is proportional to the amount of data that needs to be deleted. There are plenty of implementations of refcounting where the data is pushed into a freelist or cleaned up deferred.
Also there are generational tracing compacting collectors with (almost) no pauses, so I doubt such approach wins over them when measuring performance and fragmentation across application usages.
This is false, copying GC is a simple counterexample
EDIT: actually, it does a bit: the longer the epoch, the better, because at the end of the epoch a short stop-the-world is required to collect the global roots from registers and stacks.
How exactly?
> grinds to a halt for several seconds
What? Stop-the-world in the realtime collectors is always for a set duration, only to scan the registers and tops of the stacks (if there are any stacks at all, stackless implementations have even a better latency).
Heap fills up, you need a full collection. During that collection your program is running and allocating, but runs out of space, so it grinds to a halt.
Look, there is a reason why Rust is a thing, why realtime collectors are only used in niche cases, why there are people whose sole job is to fix GC issues, why there are people programming in Java/C# very carefully to ensure that a full heap collection never happens, etc. GC isn't a magic bullet.
It's a marginal case that should never happen, just like the case of running out of memory altogether. And RC will behave even worse in such a case.
Also, all three parts are running concurrently - marker, sweeper and mutator. Sweeper is constantly supplying the mutator with the new free cells from the current epoch, so you don't need to wait for another epoch to start getting new free cells.