In the code running at 100fps, I do a minimal amount of allocating. It's practiaclly:<br><br>(vector-for-map *some-vec* draw-object)<br><br>(define (draw-object x)<br>  (call some gl-rotate / gl-translate)<br>  (gl/CallList x))<br>
<br><br>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.<br>
<br>This data also doesn't change, except at _very_ predefined locations.<br><br>I guess if I can do somethign like:<br><br>(##gc)<br>( somehow tell gambit that the data currently left over is mostly static? )<br><br>
... continue running ...<br><br><br>That sould be ideal.<br><br>why does vector vs list mater much for ##still-copy ?<br><br>Thanks!<br><br><br><div class="gmail_quote">On Sun, Jun 14, 2009 at 5:34 AM, David St-Hilaire <span dir="ltr"><<a href="mailto:sthilaid@iro.umontreal.ca">sthilaid@iro.umontreal.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">lowly coder wrote:<br>
> Maybe the right answer is "Don't do this in Gambit", but I'd like to give it<br>
> a try:<br>
><br>
> I'm writing an application, in Gambit. It does OpenGL graphics. It runs at<br>
> 100fps. It's interpreted.<br>
><br>
> Now, put down the pitch fork -- the only thing it's doing at 100Hz is<br>
>   for 20 different objects<br>
>     glLoadIdentity<br>
>     glPushMatrix<br>
>     some rotation<br>
>     glCallList<br>
>     glPopMatrix<br>
><br>
> This works fine, _except_ when I get hit with a gambit gc, it costs me like<br>
> 70ms ... which becomes a noticable lag in my otherwise smoothly rotationg<br>
> screen.<br>
<br>
</div>If your gc costs you about 70ms, that means that your probably allocating alot<br>
of data in the heap (probably some closures?). You might want to try to limit<br>
your memory allocation to, in the end, shorten your gc times.<br>
<br>
Also, if you have big chunks of static data, ideally stuffed a flat format like<br>
in a vector or something, then you can also do a (##stil-copy obj) such that the<br>
gc will not move it in the heap after each collection. Of course, this wont work<br>
for list like structures, but should work fine for big flat define-type instances.<br>
<font color="#888888"><br>
David<br>
<br>
</font></blockquote></div><br>