When one runs out of memory, bad things happen. And Icon and Unicon are not especially focused on minimizing their in-memory requirements. Still, there may be things we can improve, such as reducing heap fragmentation, that may improve performance or allow programs to run on larger data sizes.
While the standard way to bump the BLKSIZE (and/or STRSIZE) up is via environment variables, and this works fine, it is always reasonable to ask whether the automatic behavior can be improved. We may want to increase the starting/default BLKSIZE, or better yet, since different systems have way different memory sizes, we need to make the default proportional of the system physical memory size -- does anyone know a portable call to obtain that? We may also want to tune the garbage collector for better behavior. Currently it doubles in size each time, but only after garbage collecting all previous heaps and determining that none has enough memory for a request. We may want it to more than double when it grows, and we may want it to not collect old/tenured heaps until it starts running out of memory. Much of this behavior lives in h/cpuconf.h, runtime/ralc.r, and runtime/init.r under the src/ directory if anyone wants to have a go at it. I may help, or may work on it myself if I get up some motivation. I would also like to work on some new compacter, C-friendlier representations of homogeneous structures such as lists of reals. Clint ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
