In the code running at 100fps, I do a minimal amount of allocating. It's practiaclly:
(vector-for-map *some-vec* draw-object)
(define (draw-object x) (call some gl-rotate / gl-translate) (gl/CallList x))
However, I do have _ALOT_ of static data lying around. In fact, I have large geometric models (from which I derive the open gl display lists) lying around in memory. They're vectors of lists / other vectors / other lists / ... of points / quads.
This data also doesn't change, except at _very_ predefined locations.
I guess if I can do somethign like:
(##gc) ( somehow tell gambit that the data currently left over is mostly static? )
... continue running ...
That sould be ideal.
why does vector vs list mater much for ##still-copy ?
Thanks!
On Sun, Jun 14, 2009 at 5:34 AM, David St-Hilaire <sthilaid@iro.umontreal.ca
wrote:
lowly coder wrote:
Maybe the right answer is "Don't do this in Gambit", but I'd like to give
it
a try:
I'm writing an application, in Gambit. It does OpenGL graphics. It runs
at
100fps. It's interpreted.
Now, put down the pitch fork -- the only thing it's doing at 100Hz is for 20 different objects glLoadIdentity glPushMatrix some rotation glCallList glPopMatrix
This works fine, _except_ when I get hit with a gambit gc, it costs me
like
70ms ... which becomes a noticable lag in my otherwise smoothly rotationg screen.
If your gc costs you about 70ms, that means that your probably allocating alot of data in the heap (probably some closures?). You might want to try to limit your memory allocation to, in the end, shorten your gc times.
Also, if you have big chunks of static data, ideally stuffed a flat format like in a vector or something, then you can also do a (##stil-copy obj) such that the gc will not move it in the heap after each collection. Of course, this wont work for list like structures, but should work fine for big flat define-type instances.
David