GC, the simple solution
Jeff Parsons
jeffrparsons at optusnet.com.au
Wed Jun 7 01:41:38 PDT 2006
Sean Kelly wrote:
> For what it's worth, incremental GC is similar to refcounting in that
> the cost is distributed across pointer use to avoid the need for a
> costly mark/sweep phase. I've even seen hard-realtime incremental GC
> implementations, so it's a long-term solution worth considering.
My _only_ significant beef with D so far as been the unbound time for a
garbage collection; therefore, if an incremental garbage collector built
into D could guarantee me a set maximum time would be taken for each
garbage collection (which I would manually induce as often as possible)
then unless the efficiency hit is TERRIBLE I would be all over it.
What I'm really curious about, however, is how important this is to
_other_ people - especially Walter. Would it be reasonable to say that
it seems D has been designed largely without long-term real-time
performance in mind? Sure, there are workarounds, but I haven't seen
anything elegant yet that will let me use D for such applications
without making my memory management more complicated than it would have
been in C++. Is anything in the works?
More information about the Digitalmars-d
mailing list