[racket-dev] gc vs assignment

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