Re: Stymied by Ruby's garbage collector

Bob Hutchison wrote:

> On 5/22/02 4:07 PM, "Art Taylor" <[e-mail]> wrote:
> 
>> 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.
> 
> This is the optimisation that has had the largest impact on programs I've
> written in Eiffel, Java, and Smalltalk. These all have much fancier GC
> systems that Ruby 1.6 and it still makes a big difference.

Sure, that does make sense but I feel it's a bit against the grain of a 
garbage-collected language to have to alter your code to accommodate it :-) 
 I'd rather put the same effort (in fact I intend to) into fixing Ruby's 
garbage collection to work more smoothly.

[snip Strings stuff, nope, I hardly use any]
> The timing you showed is interesting. You've got a pattern showing there.
> Are you certain you aren't doing something different in the frames with
> the long times on GC or immediately preceding those frames? Is the pattern
> reproducible? always the same frames? 

The timings shown are from a screen with a single, 8-second long animation 
with an equal number of objects each frame being involved in the 
repositioning & repainting.  I'm absolutely sure it's the GC causing 
trouble because I tried timing the two major parts of the loop 
individually: the dirty rectangle calculation and the painting.  When I saw 
a frame lagging, say taking 50ms rather than 5, I looked at the cumulative 
timings for calcuation & repainting.  Half the time (ish) it was the 
painting which took the extra 45ms, half the time it was the repositioning.

Drilling down further, I tried showing the timings for each object being 
painted in each frame, which is just a call to SDL_BlitSurface() in C.  
Nearly all the sprites being plotted took 0-1ms (so off the scale really), 
but on a 'long' frame, a particular sprite would take 47ms, and then go 
back to taking 0-1ms for the next frame.  Sometimes of course the long 
delay would happen in the repositioning loop, so the delay wasn't always 
down to that particular DLL call.

So coupled with the observation that turning off the GC got rid of these 
animation delays (until the machine ground to a halt) I concluded it was 
the GC that needed attention, or finer controls, not my code.

Like I said, once the immediate project deadlines are out of the way I'd 
like to turn my attention to implenting a different GC scheme in the 
interpreter which I'll ask about on ruby-core.

-- 
Matthew