Subject: Re: About memory limits.

From: Jan Wielemaker <[email-masked]>
Date: Mon, 28 Feb 2000 15:45:45 +0100

[Please wrap your lines at about 70 characters].

On Mon, 28 Feb 2000, Alfonso Ortega de la Puente wrote:
>I am a swi-prolog  user on Windows 95 and 98.
>	I have to handle very long lists and strings. (over 2M)
>	I have tried the following:
>	(1)  To massively increase the available memory (-L128m -G128m
> -T64m ). The system fails trying to allocate virtual memory.

So you should go a bit lower (or use a machine with more space).  Most
likely Windows 95 already checks virtual memory on VirtualAlloc().

Anyhow, a list holding 2M small objects costs 24MB (16 on many other
Prolog's, but for SWI-Prolog a list is simply a ./2 term).  Small
objects are integers below max_tagged_integer (+/-16M on a 32-bit
machine), variables or atoms (though each different atoms costs heap
storage).  Large integers and floats cost more.

>	(2) To moderately increase the available memory (numerical
>values less than before) and to use files when the length of the
>strings or lists become big enough. I know that the program uses memory
>for a lot of tasks apart from lists and strings. Could anyone to
>suggest me a rational memory strategy?. For example,  is there a
>typical relationship between the size of memory used in lists and
>strings by a program and the system  limits of memory (trail, global,
>local, etc...)?

Lists live on the global stack.  The local stack holds stack frames
for prodecure calls as well as choice-points.  The trail holds undo
information.  Determinism is the key to keep memory usage low: far
less data on the local and basically none on the trail stack, while
much less of the global stack remains reachable.

Finally, if you actually have an array, SWI-Prolog allows you to use
a term with 2M arguments (costing 8M bytes to store, you can't assert
it).

Keep the debugger off while running code like this: in debug mode
it doesn't do last-call optimisation and is less eager destroying
choice-points.

When doing serious Prolog programming (i.e. when memory or peformance
becomes a point of consideration), read "The Craft of Prolog" by
Richard O'Keefe.

	Regards --- Jan