Matthias Felleisen wrote:
Catching up with some mail.
Neil wrote:
Avoiding allocation reduces GC collects, which reduces stutters and hitches.
My (possibly old) understanding of GC and mutation tell me that this
is one of those prejudices that programmers should get rid of. Every
mutation goes across an access barrier in a GC like ours and can thus
be much more expensive than a lightweight allocation. This was
certainly true for early generational collectors. I do know that the
hordes of Java programmers who invaded GCLand forced GC builders to
make C/C++-like programs in Java work reasonably fast with collectors
and so collectors changed.
In my defense, I was talking about framerate, not total or average cost
of memory management. A GC pause in my game test app lasts 50ms to
200ms, which causes a "hitch": a noticeable, temporary drop in framerate
and responsiveness, in this case down to 20Hz to 5Hz. For comparison,
60Hz is an ideal minimum. A sequence of minor hitches is a stutter;
sometimes Racket's GC pause causes those as well.
Inflicting hitches on users in a twitch game is a cardinal sin. In
non-twitch games they are eye-wrenching, especially when everything else
is smooth. Games are really almost real-time apps.
I'm still doing the game universe-style, so I haven't moved to mutation
yet. I'm halfheartedly considering it. I'll probably try an allocation
pool of same/similar-sized arrays first. I'd gladly pay half of my ideal
16ms per frame to eliminate hitches.
Neil T
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
