No subject

a game.  I've spent many painful hours with Ruby trying to stop it from 
messing up my frame rate and only partially succeeded, much as I love the 
language for other jobs.  Once you've built your foundation on such a runtime 
there's very little you can do about it when you notice your game jerks every 
few frames.  Mark and sweep garbage collection involves forgetting about 
memory that you've allocated and every so often traversing an enormous tree 
of pointers to reclaim some memory.  If you don't do it, or delay it much, 
your program will run out of memory.  Do it as often as the language wants, 
and you'll never get a consistent frame rate.  There's also nothing you can 
do to interrupt it-- once the recovery algorithm starts it must run to 
completion or start from scratch.

Python uses reference counting to automatically free memory, and so the work 
of reclaiming memory is spread evenly over execution, rather than 
concentrated into long lumps as with GC.  See:

  http://www.gamasutra.com/features/20020821/dawson_01.htm

For how one software house's story.  This has been a public information 
broadcast from someone who's learnt his lesson with garbage collection and 
games :)  I'd be intereseted to know if anyone has used a GC as the sole 
storage solution for a game, or whether (as many people do) it's just used as 
a backstop between levels to tidy up loose ends.

-- 
Matthew       > http://www.soup-kitchen.net/
              > ICQ 19482073