No real difference on command-line. Two major collections at the start.
They are shorter (~100ms here) but noticeable. From there on only very
short minors. Maybe a forced GC right before the loop begins would help?
GC: 0:min @ 1,576K(+103K)[+148K]; free 885K(-4,981K) 0ms @ 12
GC: 0:min @ 2,240K(+3,903K)[+160K]; free 771K(-2,067K) 4ms @ 20
GC: 0:min @ 4,404K(+3,675K)[+184K]; free 1,319K(-2,615K) 8ms @ 36
GC: 0:min @ 6,111K(+3,616K)[+204K]; free 1,143K(-5,239K) 8ms @ 60
GC: 0:min @ 8,086K(+6,537K)[+208K]; free 1,433K(-2,457K) 4ms @ 80
GC: 0:min @ 11,180K(+4,467K)[+288K]; free 2,441K(-7,833K) 12ms @ 116
GC: 0:min @ 14,516K(+7,723K)[+508K]; free 3,221K(-13,989K) 16ms @ 164
GC: 0:min @ 18,678K(+15,353K)[+704K]; free 3,975K(-5,271K) 20ms @ 220
GC: 0:min @ 23,017K(+13,046K)[+736K]; free 4,528K(-7,120K) 16ms @ 284
GC: 0:min @ 28,672K(+11,247K)[+968K]; free 5,304K(-7,896K) 24ms @ 360
GC: 0:min @ 36,796K(+7,491K)[+1,000K]; free 5,174K(-34,934K) 28ms @ 452
GC: 0:min @ 48,641K(+26,606K)[+2,280K]; free 12,615K(-33,351K) 44ms @ 592
GC: 0:min @ 67,576K(+28,407K)[+3,772K]; free 21,615K(-21,615K) 76ms @ 844
GC: 0:MAJ @ 89,283K(+10,124K)[+5,676K]; free 41,635K(-70,291K) 116ms @ 1496
GC: 0:MAJ @ 80,414K(+47,649K)[+5,676K]; free 35,009K(-35,009K) 104ms @ 2124
GC: 0:min @ 78,173K(+49,890K)[+5,680K]; free 31,720K(-31,720K) 4ms @ 2748
GC: 0:min @ 79,220K(+48,843K)[+5,684K]; free 31,707K(-31,707K) 4ms @ 3280
GC: 0:min @ 80,279K(+47,784K)[+5,684K]; free 31,721K(-31,721K) 0ms @ 3836
GC: 0:min @ 81,326K(+46,737K)[+5,684K]; free 31,725K(-31,725K) 4ms @ 4364
GC: 0:min @ 82,367K(+45,696K)[+5,684K]; free 31,730K(-31,730K) 0ms @ 4892
GC: 0:min @ 83,420K(+44,643K)[+5,684K]; free 31,710K(-31,710K) 4ms @ 5420
GC: 0:min @ 84,476K(+43,587K)[+5,684K]; free 31,731K(-31,731K) 0ms @ 5960
On Thu, 08 Aug 2013 02:10:26 +0200, Greg Hendershott
<greghendersh...@gmail.com> wrote:
p.s. Trying again and using "View | Log", and letting it run a longer
time. At first, still just tiny jitters. Then I hit two major GCs,
each of which were obviously quite noticeable:
GC: 0:min @ 371,081K(+-44,377K)[+28,568K]; free 25,584K(-25,584K) 16ms @
68466
GC: 0:min @ 378,376K(+-51,672K)[+28,592K]; free 29,628K(-29,628K) 13ms @
69192
GC: 0:min @ 381,597K(+-54,893K)[+28,588K]; free 31,009K(-31,009K) 8ms @
69930
GC: 0:min @ 383,394K(+-56,690K)[+28,588K]; free 30,956K(-30,956K) 9ms @
70715
GC: 0:min @ 385,224K(+-58,520K)[+28,588K]; free 28,722K(-28,722K) 8ms @
71499
GC: 0:min @ 389,286K(+-62,582K)[+28,588K]; free 30,072K(-30,072K) 8ms @
72219
GC: 0:min @ 392,017K(+-65,313K)[+28,588K]; free 30,095K(-30,095K) 7ms @
72938
GC: 0:min @ 394,711K(+-68,007K)[+28,588K]; free 30,044K(-30,044K) 7ms @
73759
GC: 0:min @ 397,468K(+-70,764K)[+28,588K]; free 30,059K(-30,059K) 8ms @
74500
GC: 0:min @ 400,196K(+-73,492K)[+28,588K]; free 30,049K(-30,049K) 7ms @
75310
GC: 0:min @ 402,932K(+-76,228K)[+28,588K]; free 30,069K(-30,069K) 9ms @
76058
GC: 0:MAJ @ 405,652K(+-78,948K)[+28,588K]; free 196,329K(-196,329K)
548ms @ 76883
GC: 0:MAJ @ 242,109K(+84,594K)[+28,476K]; free 47,896K(-39,144K) 491ms @
78139
GC: 0:min @ 226,994K(+90,957K)[+28,472K]; free 29,742K(-29,742K) 10ms @
79233
GC: 0:min @ 230,034K(+87,917K)[+28,472K]; free 31,030K(-31,030K) 6ms @
79926
GC: 0:min @ 231,803K(+86,148K)[+28,472K]; free 29,749K(-29,749K) 8ms @
80613
GC: 0:min @ 234,835K(+83,116K)[+28,472K]; free 31,011K(-31,011K) 8ms @
81294
This in DrRacket. Robby's suggestion to run command-line is better
idea since it takes DrRacket itself out of the mix.
On Wed, Aug 7, 2013 at 8:04 PM, Greg Hendershott
<greghendersh...@gmail.com> wrote:
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
--
---------------------------------------------------------
Tobias Hammer
DLR / Robotics and Mechatronics Center (RMC)
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de
____________________
Racket Users list:
http://lists.racket-lang.org/users
