[racket] Stuttering problems with big-bang

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  
<greghendershott at 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
> <greghendershott at 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 <cce at 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  
>>> <robby at 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 at 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
>>>> <robby at 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.hammer at dlr.de