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.
