From ... From: Erik Naggum Subject: Re: Help needed in handling large LISP file Date: 1998/02/19 Message-ID: <3096867616328513@naggum.no>#1/1 X-Deja-AN: 326529317 References: <6cgaco$q2j$1@tribune.usask.ca> <34EBEEA6.4F4B482E@tif.ti.com> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp,comp.lang.scheme,comp.lang.clos * Laurent Arditi -> P. Srinivas | Are you sure your tree actually was not a graph? Even if you didn't | build it as a graph, you may have unintentional structure sharing. This | is why, you were able to construct the tree and save it but produced a so | huge file. | | The solution is: it doesn't appear that this is the problem, but if it is, I'd venture that (setq *print-circle* t) should take care of these problems in the writing Lisp image. however, it _might_ take a little longer to write the tree to disk now... if Allegro CL complains about memory problems before it finishes loading, it might be because it is trying too hard to keep objects in new-space. the macro TENURING in the FRANZ (or EXCL) package will try to make most allocations in old-space. if you know you will need a lot of old-space, you can also pre-allocate that space with SYSTEM:RESIZE-AREAS, as in: (system:resize-areas :old (* 160 1024 1024)) Allegro CL can also be built with a larger maximum heap estimate that defaults to about 120M, but I don't know what this would do to help you. there's also a LOAD-APPLICATION macro that might be useful. consult the User Guide for explanations on how to use this and the other functions mentioned. see also ROOM which should be helpful in reporting where memory is used. #:Erik -- God grant me serenity to accept the code I cannot change, courage to change the code I can, and wisdom to know the difference.