Richard, MSTKSIZE affects the likelihood of the main interpreter stack overflowing; the others do not help if you have a stack overflow. If you are doing a LOT of lists, tables, sets, records, classes, the BLKSIZE is important. If you are doing a LOT of string processing, the STRSIZE is important. Our default sizes have grown gradually over time, but are still conservative. Setting them to a super-large initial size for everyone by default would mean the language would perform poorly on machines with low memory size. We should probably set the defaults much larger anyhow.
If you run out of memory or have < 10% free after garbage collecting, the heap regions automatically allocate new, larger (50% larger each time I think) size regions to supplement the existing heap(s). This is sufficient such that most applications don't need to set these environment variables. If you don't quite run out of memory (say, 88% full after collection?), you can end up garbage collecting repeatedly (heap thrashing). Perhaps the high water mark to allocate larger regions should be < 90%, but allocating new larger heaps is not something one wants to do casually. So, your big slowdown may be because you are garbage collecting a lot, but it also (more likely) may be because you are virtual memory paging a lot. The garbage collection task itself is much more painful when virtual memory far exceeds physical memory. Some virtual memory implementations are much more efficient than others, e.g. by allocating a hard disk partition instead of a "swap file". Adding more physical memory, and making a larger swap partition or swap file might help. Cheers, Clint ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
