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