Why many programmers don't like GC?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Fri Jan 15 16:37:46 UTC 2021
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.
More information about the Digitalmars-d-learn
mailing list