On 14-Jun-09, at 2:55 AM, lowly coder wrote:
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.
What are my options?
It sounds like the problem is that your live data is big. Try running the program with the -:d2 option to see the GC statistics which look like this:
*** GC: 1 ms, 185K alloc, 198K heap, 30.6K live (15% 16640+14700)
Here the program has 30.6K of live data. A rule of thumb is that, on a typical desktop computer, each megabyte of live data will cost 2 milliseconds of garbage collection time. So it would seem that your program has about 30 megabytes of live data or so.
Note that "interpreted code" is considered to be data, because the interpreted code is represented with Scheme data (closures, vectors, lists, etc). So if your code base is big, compiling your program may reduce the live data and thus reduce the length of the garbage collection pauses. Note that in Gambit, you can mix interpreted and compiled code. Moreover, you can redefine functions (at the REPL or with load) so that the new definition of these functions is interpreted (i.e. you don't lose the ability to debug the code).
Another thing to do is to allocate program data sparingly, or use a compact representation. For data that is used infrequently, it is sometimes possible to serialize the data (into a string or a u8vector), then save it away (to a global variable or the file system), and then deserialize the string when you need to access or modify the data. This is a win because the content of strings and u8vectors is not scanned by the garbage collector, and large strings and u8vectors are not moved by the garbage collector (they are "still" objects).
Finally, you can start the application with a large heap with the -:m runtime option. Although this does not affect the duration of the GC pause, it will decrease its frequency of occurrence.
Marc