[racket] debugging memory allocation

For anyone interested, I've been able to make some progress in reducing 
GCs.  As Jay suspected, there were no magic bullets.  Just a lot of 
testing and changing code to remove intermediate lists.

My strategy so far is to test each part of the code by changing the game 
to run only that code, and frequently.  Then watch the GC lines in the 
output:
GC: 0:min @ 138,683K(+260K)[+6,816K]; free 23,990K(-23,990K) 12ms @ 37540
GC: 0:min @ 147,524K(+-8,580K)[+6,816K]; free 24,062K(-24,062K) 10ms @ 
41429
GC: 0:MAJ @ 156,293K(+-17,349K)[+6,816K]; free 94,638K(-88,638K) 139ms @ 
45517

The only number that I understand is the first one.  My measure is how 
fast that first number climbs vs. the wall clock, and how often the MAJ 
collections happen.  I guess at a code change, and see if it helps.  Not 
a great strategy, but it's slowly working for me.

I've noticed the same thing as Neil - every once in a while the GC seems 
to get into a state where the memory use is climbing 1/10 as fast as 
normal.  Sometimes it's like that from the beginning of the run, and 
sometimes it switches in the middle.  I'm not running in DrRacket.  Are 
there any GC settings I should try changing?

Thanks,
Dave


On 11/07/2014 11:51 PM, Jay McCarthy wrote:
> On Fri, Nov 7, 2014 at 11:43 PM, David Vanderson
> <david.vanderson at gmail.com> wrote:
>> On 11/07/2014 09:45 PM, Jay McCarthy wrote:
>>> Robby's advice of using backtrace can be useful. But it is pretty
>>> complicated to use, especially with an interactive application. If you
>>> go that route, you want to make an automated version of your code.
>>> Another strategy is to put your model and your view in different
>>> threads, give them different custodians, and monitor (via sampling)
>>> their memory.
>> I'll try the backtrace option if I run into a wall.  When you say automated
>> version, do you mean something like a stand-alone program that displays a
>> representative frame say 100 times, and outputs (current-memory-use) before
>> and after?  Is (current-memory-use) what you mean by "sampling"?
> Yes.
>
>>> A general strategy is to minimize allocation per-frame, use contiguous
>>> memory when you can, and reuse IT when you can. It is easy to start
>>> writing C code if you go down this path and it may not help.
>>>
>>> At a glance of your code...
>> Thank you very much!
>>
>> I was under the assumption that if my lists were generally small (~ 10
>> elements) then I wouldn't have to worry about it.
> You're right that I have no sense of how big these things are. But
> still, maybe nice!
>
>> I'll go back and start
>> testing this.  For a ring buffer, can you give an example of how to
>> implement one?
> Oh yeah:
>
> http://pkgs.racket-lang.org/#[ring-buffer]
>
>> Thanks,
>> Dave
>
>