Truth in advertising: 

big-bang skips frames in certain circumstances -- when handlers take too long 
-- so if the GC kicks in when a handler runs, it is possible that the eventual 
result is a skip. 

Robby: do you think Jack's program would benefit from a forced gc before 
big-bang runs? (I can't find Jack's code.) 

-- Matthias





On Aug 8, 2013, at 6:40 AM, Robby Findler wrote:

> Hi Jack: the entire system freezes when the GC happens and the numbers you 
> report match up with what I'd expect to be very annoying stuttering. (And 
> just for the record, it doesn't skip frames -- it just doesn't update 
> anything or draw any new frames during the GC.)
> 
> Can you tell us more about your machine? What OS and what processor?
> 
> Robby
> 
> 
> On Wed, Aug 7, 2013 at 9:55 PM, Jack Firth <the.game.creat...@gmail.com> 
> wrote:
> I started up the program from the command line with the garbage collection 
> debugging information, and saw some interesting stuff once the program was up 
> and running. Every second or so I'd see a very very slight stutter, which 
> would be followed by a garbage collection lasting either 16ms or 15ms, 
> slightly longer stutters would report as GCs of 31ms, and long freezing 
> stutters would be around 109ms. I think perhaps big-bang is doing something 
> where it's skipping a frame or two as a result of some sort of garbage 
> collection. All the on-tick etc. events are performed for the frame, it just 
> doesn't seem to be drawn. I can't fathom what's going on here.
> 
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev

_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Reply via email to