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

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

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