MLx Home | Contents
| MLx menu | MLx
buttons | Widgets | Index | What's
New | show
Memory issues
Ram assigned to the MacLispix application.
| Memory is assigned to MacLispix using the Get Info box in the finder.
MacLispix can run on 8 Meg or less, if only smaller images are processed. |
 |
| Images use two kinds of memory - Mac heap and Lisp heap. The Image
arrays are stored in the LISP heap. The scaled copy of the arrays are also
stored in the LISP heap, while the pixmap, what is actually seen on the
screen, is stored in the Mac heap. |
Printout- use Info->Print Memory Quotas buttons and click
on Monitor window. |
To save memory, the default is not to display images, thus saving space
that would be taken by the scaled image array and the pixmap. MacLispix,
since it is written in LISP, uses dynamic memory allocation. Both the Lisp
heap and the Mac heap can be reused, if one discards the images. An important
exception may be this: the Mac Heap is taken from the LISP heap as memory
is needed, and stays there even when the image window is closed.
The moral is not to show too many large images at once, or else the LISP
heap will all disappear into the mac heap, and MacLispix will run out of
memory.
In the event of seeing the GC cursor repeatedly, or getting a message
that macLispix has run out of memory, it probably be necessary to restart
MacLispix. Occasionally, it is possible to quickly close some images and
regain enough memory to continue to work.
To monitor the memory being used click the Heap button. This will show the
amounts of heap space used. Pay particular attention to the last figure
on the right - the amount of free LISP heap memory remaining. Displayed
images use Mac heap space. Image arrays use Lisp heap space. The Mac heap
will grow as more images are displayed by taking over free Lisp heap space,
but the reverse will not occur. In other words, when image arrays run out
of room, space cannot be recovered by deleting image windows - only by erasing
image arrays. The only way to get more LISP heap space is to restart MCL.
The best way to avoid the problem is to minimize the number of images displayed
at once, or, more specifically, to minimize the total image window area
at any given time.
Image memory
The memory taken by the raw data for each image is listed by the Info
button:
The above listing shows the window title (or the image name), which by default
is the file name from which the image was read. Next is the pixel data type.
(Unsigned-byte 8) is the usual byte image format. Note that this does NOT
indicate whether or not the image is a gray scale image, or a false colored
image using an LUT. (Unsigned-byte 16) images are sometimes known as 'integer
images', but there are other types of integer images than this. The last
collumn is the memory requirement in Kbytes (kilobytes = 1024 bytes).
When the image is actually displayed, additional memory is used for the
pixmap, and sometimes for a scaled version of the image. (The memory requirement
for a bit image, for example, is about an order of magnitude larger than
the size of the original data array.)
For special types of images, such as the blobber, superblobber, EDIF
spots, and stacks, each image window uses considerably more memory.