On Fri, Nov 7, 2014 at 11:43 PM, David Vanderson <david.vander...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
