On Sun, Jun 14, 2009 at 7:19 AM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

On 14-Jun-09, at 9:35 AM, lowly coder wrote:

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!

Are you using plain Scheme vectors to store your numeric data? Here it will pay off to use f32vectors, f64vectors or any homogeneous numerical vectors. That's because the content of these vectors are not scanned by the garbage collector. As I said in a previous message, if these vectors are still objects they will not be moved by the garbage collector, which further reduces the time needed. You can force an object to be still by passing it to ##still-copy. For example:

> (define v (f32vector 1. 2. 3.))
> (define v2 (##still-copy v))
> (list v v2)
(#f32(1. 2. 3.) #f32(1. 2. 3.))
> (##still-copy (list 1 2 3))
(1 2 3)

Note that in the last call to ##still-copy, a still copy is only created for the pair at the head of the list. In other words ##still-copy does a shallow copy. If you want a deep copy you have to code it yourself. That's why David said ##still-copy is less useful for lists.

An alternative is to store the data as C data, and use the FFI to access it. The difficulty level will depend on the data and how you manipulate it.

If you want to allocate "constant Scheme data" the only option right now is to create a Scheme file like:

(define my-constant-data '#f32(1.0 2.0 3.0))

then compile the file with gsc and load the object file into your running application.

I'm working on a solution for allocating constant data at run time, but it is low on my TODO list.

Marc