[racket] debugging memory allocation

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Fri Nov 7 23:51:30 EST 2014

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"?


>> 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:


> Thanks,
> Dave

Jay McCarthy

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

Posted on the users mailing list.