Re: Fast allocation vs lightweight collection

> > I have a question for you again. What do you think is better a Fast
> > allocation process or a lightweight collection?

If you have not already, you may want to read the best reference on the
subject:

Garbage Collection: Algorithms for Automatic Dynamic Memory Management
by Richard Jones, Rafael Lins

> In appliactions where pauses are unacceptable, there is no way to
> "work around" the problem.
> 
> Constant factor performance degredation is not relevant. Computers get
> faster every year, it is easy to use more computers, and in the rare
> windows of time where this is a problem for a specific application,
> they are probably writing in C instead of C# anyhow.

The performance overhead of garbage collection is somewhere between +20%
(reference counting with lots of pointer writes) and -5% (very efficient
generational collector which reduces the allocation time, improves the
memory locality and produces an overall improvement), with perhaps +5%
being typical. When comparing to C++ you also have to account for vector
bounds checking, null pointers... adding some more.

The real problem in most cases, and in almost all interactive
applications, is indeed garbage collection pauses.

I had experience with the development of an emergency call management
system written in Modula-3 where the pause times for a large heap were
of several seconds every few minutes. When we switched to an incremental
collection algorithm the pauses became much smaller (.1 or .2 seconds).
It was probably a bit less efficient CPU wise but only by a few percent.

One very important point that did not come out in the discussion is the
interaction between garbage collection and multi-threading. Most
algorithms need special treatment or are inapplicable in multi-threaded
environments. Reference counting, for instance, needs some form of
locking when updating the reference counts, unless you rely on the
application to do its own locking and not modify a pointer from two
threads.



_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list