On Friday, 15 January 2021 at 16:26:59 UTC, Guillaume Piolat
wrote:
Until someone can describe a strategy that works for a full
application, e.g. an animation-editor or something like that,
it is really difficult to understand what is meant by it.
Personal examples:
- The game Vibrant uses GC for some long-lived objects.
Memory pools for most game entities.
Audio thread has disabled GC.
But when do you call collect? Do you not create more and more
long-lived objects?
- Dplug plugins before runtime removal used GC in the UI, but
no GC in whatever was called repeatedly, leading to no GC pause
in practice. In case an error was made, it would be a GC pause,
but not a leak.
How do you structure this? Limit GC to one main thread? But an
audio plugin GUI is not used frequently, so... hickups are less
noticable. For a 3D or animation editor hickups would be very
annoying.
The pain point with the mixed approach is adding GC roots when
needed. You need a mental model of traceability.
Yes. I tend to regret "clever" solutions when getting back to the
code months later because the mental model is no longer easily
available.
I think it is better with something simpler like saying one GC
per thread, or ARC across the board unless you use non-arc
pointers, or that only class objects are GC. Basically something
that creates a simple mental model.
It really is quite easy to do: build you app normally,
evetually optimize later by using manual memory management.
I understand what you are saying, but it isn't all that much more
work to use explicit ownership if all the libraries have support
for it.
It is a lot more work to add manual memory management if the
available libraries don't help you out.
