> If you have real-time needs, then GC is probably out. That includes handling audio and video playback. You'd be surprised. At first our D audio products had

> If you have real-time needs, then GC is probably out. That includes handling audio and video playback. You'd be surprised. At first our D audio products had GC enabled, and that created very little problems. When we got rid of the D GC for other reasons (macOS + druntime portability in shared library), we found that we only gain in memory usage. The GC was already "tamed" to happen outside real time threads. This is described in: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html https://www.auburnsounds.com/blog/2016-11-10_Running-D-witho... The conclusion: > Long story short, we brute-forced our way into having fully @nogc programs, with the runtime left uninitialized. > As expected this fixed macOS Sierra compatibility. As a bonus Panagement and Graillon are now using 2x less memory, which is nice, but hardly life-changing. > We found no magical speed enhancement. Speed-wise nothing changed. Not registering threads in callbacks did not bring any meaningful gain. GC pauses were already never happening so disabling the GC did not help. > In conclusion, it is still our opinion that outside niche requirements, there isn't enough reasons to depart from the D runtime and its GC. And indeed now we dearly miss the GC... For sure you wouldn't allocate in tight loops. But the portion of a program that can accomodate a GC is very much larger than is commonly told on the internet. As for video, it is way less sensitive to scheduler pauses than audio. Video systems are full of allocations (often of commited virtual memory) because throughput is often more important than latency there.