From: Art Taylor Date: 2002-05-23T05:07:45+09:00 Subject: Re: Stymied by Ruby's garbage collector 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" wrote in message news:... > 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 > >