dsimcha wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> dsimcha wrote:
>>> Yes, and similarly, when I write code to do some complicated processing of gene
>>> expression data or DNA sequences, and it uses RAM measured in gigabytes, I go to
>>> similar lengths to avoid GC for similar reasons.  (That and false pointers.)  It's
>>> not unique to server space.  The reason I still use D instead of C or C++ is
>>> because, even if I'm using every hack known to man to avoid GC, it's still got
>>> insane metaprogramming capabilities, and it's still what std.range and
>>> std.algorithm are written in.
>> Generally, GC only works well if the size of your allocations is << the
>> size of the memory. Are you working with gigabyte sized allocations, or
>> just lots of smaller ones?
> 
> Little from column A, little from column B.

The giant allocations might be better done with malloc.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> dsimcha wrote:
> > == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> >> dsimcha wrote:
> >>> Yes, and similarly, when I write code to do some complicated processing of gene expression data or DNA sequences, and it uses RAM measured in gigabytes, I go to similar lengths to avoid GC for similar reasons.  (That and false pointers.)
 It's
> >>> not unique to server space.  The reason I still use D instead of C or C++ is because, even if I'm using every hack known to man to avoid GC, it's still got insane metaprogramming capabilities, and it's still what std.range and std.algorithm are written in.
> >> Generally, GC only works well if the size of your allocations is << the size of the memory. Are you working with gigabyte sized allocations, or just lots of smaller ones?
> >
> > Little from column A, little from column B.
> The giant allocations might be better done with malloc.

Yes, this is one of those "hacks" that I use to avoid GC.