On Sun, 2009-01-11 at 01:23 +0100, Thomas Chust wrote: > Hans Vercammen wrote: > > On Sat, 2009-01-10 at 13:16 -0800, Noah Gibbs wrote: > > [...] > >> Remember that an object can be part of more than one cycle, and you > >> have to know how many of those refs are "cyclic" refs, and how many > >> (if any) aren't from cycles. That's non-local knowledge. What I'm > >> saying is that it's not an easy think to calculate, and there's a > >> reason that garbage collectors tend to be slow :-) > > > > There are actually rather fast garbage collection algorithms out there. > > The main reason I can think of why they still appear to be slow is that > > in most cases they have to "stop the world" to do their processing. > > [...] > > Hello, > > there are also real-time garbage collectors that never need to stop the > program for more than a few microseconds and can run concurrently with > the main program on a separate thread. > > Garbage collection isn't necessarily slow, if it's implemented well. The > trick is to make the extra work happen concurrently with the main > program and / or at convenient points in time. Especially if you have a > lot of memory and can afford to just allocate objects, deferring cleanup > until the main program is idle, garbage collection is usually faster > than manual memory management or reference counting which incurs more > calls to the allocator at inconvenient points in time.
I'm not sure what the actual benefit would be that way. In general I would agree, but if you mean running the garbage collector in a different thread; it would imply more synchronization mechanisms, which would also slow down the process significantly. Not all programs have a main idle loop or are multi-threaded by default. The main idea of reference counting is to take care of the object life-cycle immediately without prosponing it to a different process/thread. Hans _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
