Why many programmers don't like GC?
Guillaume Piolat
first.last at gmail.com
Fri Jan 15 18:43:44 UTC 2021
On Friday, 15 January 2021 at 16:37:46 UTC, Ola Fosheim Grøstad
wrote:
>
> But when do you call collect? Do you not create more and more
> long-lived objects?
Calling collect() isn't very good, it's way better to ensure the
GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (noting that things that can't
contain pointer, such as ubyte[], scan way faster than void[])
>
> 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.
Yes but when a hiccup happen you can often trace it back to
gargage generation and target it. It's an optimization task.
> I think it is better with something simpler like saying one GC
> per thread
But then ownership doesn't cross threads, so it can be tricky to
keep object alive when they cross threads. I think that was a
problem in Nim.
>> 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.
But sometimes that ownership is just not interesting. If you are
writing a hello world program, no one cares who "hello world"
string belongs to. So the GC is that global owner.
More information about the Digitalmars-d-learn
mailing list