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