The purpose of D (GC rant, long)

[Dave]

Sean Kelly wrote:
> Kyle Furlong wrote:
>>
>> That said, isnt one able to disable the GC through std.gc.disable() or 
>> some such call? What exactly does it do, now that I think about it? 
> 
> When memory is allocated from the GC it first looks to see if it has any 
> available internally.  If it can't find any it runs a collection and 
> looks again.  If it still can't find any then it obtains more memory 
> from the OS and uses a portion of that for the allocation.  Setting 
> gc.disable() prevents the collection run from occurring so the GC will 
> simply obtain more memory from the OS when it runs out.  The reason 
> behind this is that collections can take a long time, and 
> performance-critical sections of code don't necessarily want to wait for 
> a collection to occur just because they called 'new'.  So they'll either 
> disable and re-enable the GC around critical sections of code or they'll 
> simply keep the GC disabled and manually collect during idle periods 
> using gc.fullCollect().
> 
>> Perhaps, for cases such as this, it would be helpful for there to be a 
>> page on digitalmars.com/d/ which lists the language features that are 
>> gc supported such that any prospective developers of the OP's bent can 
>> easily avoid the allocations and memory waste they dont want to invoke.
> 
> Now that memory is not freed when string.length is set to zero it's 
> quite possible to avoid most reallocations simply by preallocating in 
> buffers before using them (ie. set length to some large number and then 

I did not know that had been changed.. Is that now part of the language 'spec' somewhere as well?

I'm betting this has been discussed or at least proposed, but here goes again; let's get an 
array.reserve at least for native arrays (that could be implemented as {arr.length = nnn; arr.length 
= 0;}). That way it would make for less of a hack than re/setting the length, and also codify it as 
part of the language.

> back to zero).  However, some operations will still cause an allocation, 
> such as appending to a slice.
> 
> 
> Sean