This is why I'm happy to see some people (Leandro in particular) are already working on different GC designs for D. :)
So to evade the GC's pauses as much as possible, one would stick with using structs or preallocate all needed data before a critical section? I'll have to get more into that eventually, one of my future goals (future as in years+ from now) is to make a realtime musical app (a sequencer). On Sat, Sep 11, 2010 at 2:15 AM, Jonathan M Davis <[email protected]> wrote: > Yeah. That's actually generally where GCs end up causing performance problems. > It's not the fact that they have to grab more memory from the OS or give it > back > but rather the fact that it takes the time to figure out what it can put back > in > its own memory pool. Even worse, in most GCs, it's completely underministic > when > that could happen, so it could end up slowing down your program at critical > moments. For most apps, that doesn't really matter, and I suspect that D's is > currently somewhat more deterministic than most since it only runs the GC code > when new is called as opposed to having its own separate thread, but it's a > common criticism of GCs. The other would have to do with their memory > consumption which stems from the fact that they maintain a memory pool and are > essentially guaranteed to be holding more memory that you would if you freed > memory immediately when you were done with it. Now, that doesn't necessarily > mean that they're less efficient - that depends on the GC and can be hotly > debated > - but it does mean that your program will require more memory using a GC than > not. > > - Jonathan M Davis >
