3 ms·
No, but ARC does not have to pause all threads. Also this exists: https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2949656-deallocate ht
by zelly 7y ago
No, but ARC does not have to pause all threads. Also this exists:
https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2949656-deallocate https://developer.apple.com/documentation/swift/unsafemutabl...
- fulafel 7y agoSo your scenario there is a separate thread that doesn't generate or free garbage? Because if it does, there will be synchronization inside malloc/free and your thread will pause. Also the Swift compiler is unpredictable about when it will use the heap instead of stack, allocations are not explicit. So it might be hard to accomplish in practice. I agree that this special case could be more realtime with ARC, but on other GCs such an isolated worker can be implemented as a separate program instance (separate process or separate VM instance in same process) that has memory allocation and GC disabled after init. In the other cases where you keep whe GC on, I think the low-pause GCs of today should be suitable for tasks like computer vision in cars because the pause times are so short (sub-millisecond) vs the processing time for a frame. And the generally higher performance of non-rc GC should more than make up for it.