Is there a particular kind or kinds of object being created in huge numbers?
Can you pool those and reuse them rather than throwing them away?

-a.

"Matthew Bloch" <mattbee / soup-kitchen.net> wrote in message
news:<acgf0l$f6k$1 / knossos.btinternet.com>...
> Nat Pryce wrote:
> 
> > I had the same problem writing a game in Eiffel, also using the SDL. 
> > Here's the steps I took:
> > 
> > 1) Explicitly invoked the GC each frame.  That ensured that there was
> > about the same amount of delay for GC every frame, instead of sudden
> > lurches every few seconds.
> 
> This is what happens:
> 
> 02-05-22 16:47:13:823326 ./game/lib/overlay.rb:356:in `poll' | GC took 22
> 02-05-22 16:47:13:847979 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:13:869757 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:13:891188 ./game/lib/overlay.rb:356:in `poll' | GC took 20
> 02-05-22 16:47:13:912836 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:13:940630 ./game/lib/overlay.rb:356:in `poll' | GC took 27
> 02-05-22 16:47:14:128456 ./game/lib/overlay.rb:356:in `poll' | GC took 188
> 02-05-22 16:47:14:152023 ./game/lib/overlay.rb:356:in `poll' | GC took 23
> 02-05-22 16:47:14:173605 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:14:195064 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:14:216440 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:14:375268 ./game/lib/overlay.rb:356:in `poll' | GC took 159
> 02-05-22 16:47:14:405899 ./game/lib/overlay.rb:356:in `poll' | GC took 30
> 02-05-22 16:47:14:427822 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 02-05-22 16:47:14:647790 ./game/lib/overlay.rb:356:in `poll' | GC took 219
> 02-05-22 16:47:14:693069 ./game/lib/overlay.rb:356:in `poll' | GC took 45
> 02-05-22 16:47:14:722121 ./game/lib/overlay.rb:356:in `poll' | GC took 28
> 02-05-22 16:47:14:743437 ./game/lib/overlay.rb:356:in `poll' | GC took 21
> 
> So even when I call GC.start before EventQueue.poll (since null events 
> drive the animation), I get these totally unpredictable delays.  I think 
> (unless I'm misinterpreting this) that I'm going to have to lump it for
now 
> and do something with Ruby's garbage collector for another release.
> 
> Damn.
> 
> > 2) Ran the animation loop as fast as possible (with a tiny delay to
allow
> > the OS to collect events), rather than using a delay to force a fixed
fps.
> > Fed the length of each frame into the simulation as the duration of the
> > next frame.
> 
> There's no delay in it currently, and all the animation elements have
their 
> own idea of time from SDL_TimerTicks.  The frame-rate smoothing would be a

> nice addition, I'll probably do that later too, since the game is built on

> a basic GUI / animation toolkit, but the system load is reasonably 
> predictable on the terminals so it's not really necessary for this
release.
> 
> -- 
> Matthew
> 
>