slow runtime

Andrej Mitrovic andrej.mitrovich at gmail.com
Fri Sep 10 17:36:06 PDT 2010


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 <jmdavisprog at gmail.com> 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
>


More information about the Digitalmars-d-learn mailing list