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

[Mike Spertus]

> "Purify is not a garbage collector.  It "solves" the problem of memory
> leaks by pointing leaks out to you, which you in turn fix.  A real GC
> solves memory leaks by automatically deallocating memory for you when
> there's no more pointers to the memory in question."
> 
> That's technically correct.  But last I checked, Purify's leak detection
> mechanism was essentially the same mechanism that could be used to implement a
> basic conservative garbage collector.  It traces reachable memory, and looks
> for unreachable objects that haven't been freed.  Our collector can be compiled
> to perform the same sort of check on malloc/free code, but with less
> sophisticated output.  Thus I think the original question about relative
> performance makes sense, in spite of the fact that its primary intended use is
> very different.
> 
I hope I didn't convey the impression that the question didn't make sense,
but I think the answer I gave is correct.

Logic equivalent to GC may be buried inside of Purify, but there is a
whole lot more diagnostic work with overhead going on. All memory accesses
are usually instrumented, which has a huge amount of overhead but catches
the widest variety of possible errors. Also, even for the shared logic, the
great difference in intended use will result in radically different tuning.
For example, I assume Purify's allocator is a debug allocator, which by itself 
makes programs sluggish (this is true for the debug allocation mode in GCs as 
well, but there's no reason for debuggers to have a non-debug mode).