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, an
On Fri, Nov 7, 2014 at 11:43 PM, David Vanderson
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 ve
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 vi
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 c
(Despite the fact that 'cool' appears in it twice Don't look at me
for writing tips, apparently!)
On Fri, Nov 7, 2014 at 7:45 PM, Matthias Felleisen wrote:
>
> On Nov 7, 2014, at 5:52 PM, Robby Findler wrote:
>
>> It would be really cool if someone were to build some cool memory
>> performan
On Nov 7, 2014, at 5:52 PM, Robby Findler wrote:
> It would be really cool if someone were to build some cool memory performance
> debugging tools for Racket, tho.
For people out there looking for a dissertation topic, this is a good line to
start from.
Racket Users li
Unfortunately, it is hard to separate these things when you're running
in DrRacket because DrRacket is doing lots of complicated things that
foul your measurements.
I think you can display interactive 3d snips outside of DrRacket. Just do this:
#lang racket/gui
(define f (new frame% [label ""]))
Please, someone answer this man! I need to do the same kind of debugging
on Pict3D.
One thing I've noticed from just dumping the result of
(current-memory-use) to the terminal: sometimes memory use will
repeatedly climb until there's a major GC, and sometimes minor GCs will
be enough to keep
I'm having a UI problem in my game where major GCs cause noticeable,
frequent pauses (every 5-15 seconds). Jay's advice was to control
allocation. Minor GCs are no problem, and I'm okay with infrequent
major GCs.
Problem is I don't know how to go about tracking this down, and need
advice.
9 matches
Mail list logo
