From jan@swi.psy.uva.nl  Tue Jun 13 14:59:46 2000
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id OAA24083;
	Tue, 13 Jun 2000 14:59:45 +0200 (MET DST)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id PAA25291;
	Tue, 13 Jun 2000 15:00:27 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Paul Sephton <paul@inet.co.za>
Subject: Re: Heap heaping up?
Date: Tue, 13 Jun 2000 14:37:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: prolog@swi.psy.uva.nl
References: <Pine.LNX.3.91.1000610010844.11867A-100000@pdev.inet.co.za>
In-Reply-To: <Pine.LNX.3.91.1000610010844.11867A-100000@pdev.inet.co.za>
MIME-Version: 1.0
Message-Id: <00061315002702.24662@gollem>
Content-Transfer-Encoding: 8bit

On Sat, 10 Jun 2000, Paul Sephton wrote:
>On Fri, 9 Jun 2000, Jan Wielemaker wrote:

>> It seems there is a memory-leak in consult.  This doesn't really
>> surprise me.  Consult is for loading sources and it does a lot of
>> bookkeeping to deal with editing, re-consult, etc.  A small amount
>> of leakage isn't too bad as source-files are loaded only once, or
>> at most a few times during debugging.
>
>_small_ leak??  this proggie doen't take long to reach 12MB of heap 
>usage;  The odd thing is that it seems to happen spuriously-  a number of 
>iterations, and then bang- another 4 MB or so (not K).

Thanks to Paul for tracking the problem down to a leak in
sformat/swritef.  Fixed in my internal version (revision 1.91 of
pl-prims.c on the CVS repository).  The `bangs' are probably be caused
by the malloc() implementation used.  Note that this leak affects all
code using sformat or swritef.  This includes most of the messages
written by the system.

>> In general, don't use consult/1 and friends for external storage
>> of terms.  Simply use read and write for this.  Reading a file is
>> easy:
>....
>> This way you avoid loosing dynamic declarations, the overhead
>> of source-administration, macro-expansion, style-checking, etc.
>> 
>> 	Regards --- Jan
>
>read_file/1 as you defined, works well in most instances, but meet the 
>lazy programmer... I really don't like reinventing wheels.

It's not really reinventing the wheel.  It is saying what you want to
achieve: input and output clauses of the dynamic Prolog database to a
file.  Consult is for loading programs.  That too loads predicates from
a file, but it does a lot more and has various side-effects which you
may or may not like.

>I actually quite like consult dropping those predicates for me and also 
>the automatic check for whether the file has changed.  It lets me 
>interact between two instances of prolog quite nicely.

Never though of that use.  When finished, the external term database
will provide means for achieving that (also network transparent).

>Ok, boss, I'll do it your way... or perhaps I'll go look for that leak 
>myself :-)

Thanks for doing so (and finding something much more important than just
consult).   Nice thing with opensource software is that anyone can be
the boss if s/he want to :-)

	Regards --- Jan

