The problem with the D GC

[Bill Baxter]

Sean Kelly wrote:

>> This seems to be a very big issue.  The GC seems to be pretty much 
>> useless right now if you're going to have a lot of floating point data 
>> in your app.
> 
> For what it's worth, I ran the test above with the modified GC in Tango, 
> for 10000 iterations of the "while(1)" loop.  The default behavior 
> roughly matched Phobos, with an 89 second run time and over 340MB of 
> memory consumed and growing steadily.  Then I told the GC to not scan 
> the arrays using the following calls:
> 
>     gc.setAttr( data.ptr, GC.BlkAttr.NO_SCAN );
>     gc.setAttr( incoming.ptr, GC.BlkAttr.NO_SCAN );
> 
> A test with these changes in place dropped the run time to 7 seconds 
> with 43MB of memory consumed and not growing.
> 
> I grant that this isn't quite as nice as if D just figured out whether 
> to scan the block using TypeInfo, but at least it grants the programmer 
> a way to customize GC behavior somewhat to tune application performance. 
>  The only stipulation with the current implementation is that block 
> attributes will not be preserved if an array is resized.  This isn't 
> terribly difficult to fix, but I haven't done so yet.

I'd certainly be willing to do that sort of thing in my code to make the 
problem go away in the short term.  In my case all of those setAttr 
calls would be hidden away in library code, so it wouldn't make life any 
harder for everyday use.

But it's not much use as a workaround until Tango is actually 
downloadable somewhere.  :-)

Once Tango is available, though, that would certainly be better than the 
alternative of rewriting my library to use malloc/free.  If that's going 
to be necessary then I think I'll just as soon go back to C++ where at 
least I can use smart pointers.  The integrated GC is the #1 reason I'm 
using D in the first place, and if I can't realistically use that then I 
might as well be using C++.

--bb