[gclist] Purify Find new leaks performance / Real GC performance

[Mike Spertus]

> The only time I have used a GC on our C code, is Purify (A C checking 
> tool, that find leaks).  Doea anyone have some ideal how its speed
> comparse to the speed of a conservative GC.
> 
> I find that Purify, take a long to time find leaks, much longer then
> we could put up with from a GC, but using a conservative GC would be
> nice.
> 
> Ian Ringrose
> ianr@lsl.co.uk
> 
> 
Conservative GC, such as in our product or in Boehm's collector, will
provide far higher performance but not address the same set of errors. 
Essentially, GC's and diagnostic tools are different categories of tools.

A debugger will do whatever it takes to provide the most information about
the widest variety of errors. This is a good choice for a debugging tool, 
which of course is only attached to the program during testing. For example, 
Purify will insert code to validate each memory access because it will 
diagnose the widest variety of memory errors, such as attempts to use 
uninitialized data (which will not be flagged by a GC). 

By contrast, a GC becomes a permanent part of the program and cannot afford 
to slow down a program, so it will focus primarily on automating memory 
deallocation. Using conservative GC automatically eliminates memory deallocation 
errors and does not require running validation checks on memory accesses.
In particular, well-implemented GC does not have a significant effect on
program performance. (GC'ed programs are approximately the same speed as
manually managed programs, sometimes slower but often faster. In almost all
cases, using some of the development time saved by GC to focus specifically
on optimizing a program's overall performance is the best performance 
programming strategy.)