http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- 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 > 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 https://github.com/dsimcha/druntime/wiki/Druntime-GC-Optimization-Fork . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
