Thanks, I think swapping and controlling the GC would be a very useful feature.
In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass.
In other words, it's better to do a bit of GC every frame than a bunch at once and risk stuttering.
(Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)
I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs
Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass.
In other words, it's better to do a bit of GC every frame than a bunch at once and risk stuttering.