[plt-scheme] asking mzscheme and DrScheme to GC less to get speedups at the expense of memory usage?

I have some memory-hungry and compute-intensive programs that I'm running in DrScheme under Mac OS X and in mzscheme under Linux. Under DrScheme I set the memory limit to something fairly high, while under Linux, if I understand correctly, there is no limit.

In both cases, however, less memory is actually being used than I would expect. I suppose this means that a lot of the memory turns quickly to garbage and is being quickly collected, which is nice in some respects, but in the current case I want maximum execution speed and would be happy for the thing to eat several GB more memory if that would help things to run faster.

The reason I suspect this might be possible is that I used to experience similar things in various Lisps, and I could get substantial speedups by telling them to GC less. For example, in CMUCL the default GC parameters would always cause my programs (which are often genetic programming systems with large populations) to thrash in GC and run very slowly overall, but if I launched CMUCL with a command-line argument that told it not to GC until a particular (high) threshold of allocation was reached then it would run much faster. This makes a big difference for runs that can take hours or days.

Is there a way to do something similar with mzscheme and/or DrScheme? Or would it not help for some reason? I'm currently conducting a run that I would expect to eat lots of RAM and it's using a measly 1.9% of my system memory. I'd be happy for it to use 99% if that would improve the runtime.

I've browsed the reference and found a number of sections related to GC but nothing addressing this issue specifically.

Thanks for any help you can provide,

 -Lee

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/