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. However, implementing a good garbage collector is far from trivial. And manual memory management certainly wastes less space. cu, Thomas _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list