3 ms·
Tracing GC has much better throughput than reference counting GCs (yeah, they both are GC algorithms), especially when compared against Arc<>, which would be qu
by gf000 2y ago
Tracing GC has much better throughput than reference counting GCs (yeah, they both are GC algorithms), especially when compared against Arc<>, which would be quite expensive if many objects were making use of it, due to the synchronization overhead. (Note: I'm not saying that Rust would be slow or anything, as you can precisely go as low-level as you wish and circumvent the price of any form of GC. But if you were to have a lot of Arc objects around, e.g. you use them to represent stuff the user can also manipulate and thus have completely opaque lifetimes, then the overhead can become non-negligible)
Tracing GCs can do most of the work completely independently of the user code, and in parallel. Also, only live objects are touched, which can be also beneficial for certain kinds of applications.
- zozbot234 2y ago> Note: I'm not saying that Rust would be slow or anything, as you can precisely go as low-level as you wish and circumvent the price of any form of GC. Rust can also circumvent some of the overhead of Arc<> as it can update the reference count whenever a true "owner" is added or removed, as opposed to just any reference to the object. But yes, you're right that relying on automated reference counting as the default memory management strategy involves some overhead, and tracing GC may be preferable to that. This is a big issue wrt/ Swift.