--- Comment #114 from David Simcha <dsim...@yahoo.com> 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
> 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
> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------