I didn't get any noticeable jitter. Noticed I had "Racket | Limit Memory..." set to 2048 MB.
I reduced it to 64 MB. Still no jitter. I cranked it down to 8 MB (the minimum). Then I got some jitter. Not extreme, but noticeable. The variance in people's reported experiences might be due (partly) to that? On Wed, Aug 7, 2013 at 6:16 PM, Carl Eastlund <c...@ccs.neu.edu> wrote: > For reference, I was on IRC with Jack when he first ran into this, and > reproduced the jittery behavior on my own machine with a freshly started > DrRacket. The first time I ran the program, and perhaps every 10th time I > ran it, it would hiccup briefly within a second of hitting run, then run > smoothly. This is on a relatively recent Mac Mini with 16 GB RAM, 4 > physical / 8 virtual cores, and little else running at the time. > > Carl Eastlund > > On Wed, Aug 7, 2013 at 5:22 PM, Robby Findler <ro...@eecs.northwestern.edu> > wrote: >> >> I just tried this on my mac (a fairly recent machine but not a super-duper >> powerhouse) and it didn't seem jittery. >> >> What happens if you save it in "file.rkt" and, from a terminal window, run >> "racket file.rkt"? Here's the precise command I ran (on a mac): >> >> /Applications/Racket\ v5.3.5/bin/racket -W debug@GC ~/file.rkt >> >> I didn't see too many GCs once the game started and the ones I saw were >> unlikely to be noticeable (they were 3-5 msec; well below the 16 msec screen >> refresh rate). >> >> If that makes a difference on your machine, perhaps that means it is time >> to restart DrRacket (as GCs can take significantly longer for programs >> running inside DrRacket, esp. if there is a leak somewhere). >> >> Robby >> >> >> On Wed, Aug 7, 2013 at 2:58 AM, Robby Findler >> <ro...@eecs.northwestern.edu> wrote: >>> >>> Well, allocation is what triggers GC and there appears to be a fair >>> amount of that in your program. I am not in a good position to run your code >>> and nothing jumps out at me from a first glance at the gist but probably it >>> is allocation that originates there (not that that >>> means your code is necc. buggy). >>> >>> Fundamentally, functional image construction (and lists) requires >>> allocation and allocation requires GC. That said there is probably >>> something's we can fix here. I will try to take a closer look in the coming >>> days of no one beats me to it. >>> >>> Robby >>> >>> >>> On Wednesday, August 7, 2013, Jack Firth wrote: >>>> >>>> Hey users, I'm experimenting with some simple games using big-bang from >>>> 2htdp/universe and I keep running into stuttering problems. It seems to be >>>> the garbage collector slowing things down (green recycle symbol in drracket >>>> is on whenever the program is frozen). >>>> >>>> Increasing the memory limit or removing the limit altogether doesn't >>>> seem to affect the problem, and I've checked in the IRC and it occurs on >>>> other machines as well, all of which have the specs that it shouldn't have >>>> any problems with slowdown. Are there issues with big-bang and it's event >>>> handling? >>>> >>>> Source - https://gist.github.com/Universalist235/6171371 >> >> >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users >> > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > ____________________ Racket Users list: http://lists.racket-lang.org/users
