how to use GC as a leak detector? i.e. get some help info from GC?

[Nick Sabalausky]

"nobody" <no at where.com> wrote in message 
news:gvc5q7$2bc3$1 at digitalmars.com...
> Hi,
>
> I'm writing a data processing program in D, which deals with large amounts 
> of
> small objects. One of the thing I found is that D's GC is horribly slow in
> such situation. I tried my program with gc enable & disabled (with some 
> manual
> deletes). The GC disabled version (2 min) is ~100 times faster than the GC
> enabled version (4 hours)!
>
> But of course the GC disabled version still leak memory, it soon exceeds 
> the
> machine memory limit when I try to process more data; while the GC enabled
> version don't have such problem.
>
> So my plan is to use the GC disabled version with manual deletes. But it 
> was
> very hard to find all the memory leaks. I'm wondering: is there anyway to 
> use
> GC as a leak detector? can the GC enabled version give me some help
> information on which objects get collected, so I can manually delete them 
> in
> my GC disabled version?  Thanks!
>

Depending how exactly your program is working, another common thing that 
might help is to manually manage free pools. Ie, allocate a bunch up-front, 
and instead of letting one get GCed when done with it, hold on to it, make 
note of it being available for re-use, and then reuse it instead of 
allocating a new one. Or, allocate one big chuck of memory and stick your 
small objects in there. They typically do this sort of thing for particle 
systems.