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