Theoretically, you could recompile the GC to write to a log file any
time it frees anything.
For data processing, though, you really want to try to have a fixed
memory buffer. You've got to be hurting from the allocations and frees,
which if at all possible you should get rid of.
Also, if you're allocating buffers of memory (e.g. for the data), you
can tell the GC not to scan them. This will probably solve the problem
of the GC being so slow.
-[Unknown]
nobody wrote:
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!
