--- Comment #114 from David Simcha <> 2011-04-14 18:23:13 PDT 
(In reply to comment #113)
> (In reply to comment #112)
> > Anything with hard realtime requirements cannot do allocation - even in 
> > C/C++,
> > malloc() does not have an upper limit on its time.
> > 
> > What is done is to pre-allocate everything necessary before entering the 
> > hard
> > realtime section.
> This does not apply to the discussion. Video games do not have hard-realtime
> requirements.
> Garbage collection speed dictates how much work must the programmer do to
> offset the GC's slowness. If the GC is fast enough that it does not cause
> performance issues on systems satisfying the game's minimum system
> requirements, the programmer doesn't need to care about it at all. Otherwise,
> they must do some work (the slower the GC, the more work) to reduce the size 
> of
> the heap, or the number of allocations, or ultimately abandon heap allocation
> entirely. This might be easy in simple video games, but becomes increasingly
> painful in very large projects, with non-trivial user interfaces etc.
> So, by making the GC slower, you are creating more work for me. I am not happy
> about it.

How about this:  I can virtually guarantee that any slowness caused by precise
heap scanning is more than offset by my recent patches (in Git but not in any
DMD release yet).  See .

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to