From jan@swi.psy.uva.nl  Mon May 15 10:35:45 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 KAA25943;
	Mon, 15 May 2000 10:35:44 +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 KAA06954;
	Mon, 15 May 2000 10:35:55 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Paul Sephton <paul@inet.co.za>, Paul Singleton <p.singleton@keele.ac.uk>
Subject: Re: String Representation
Date: Mon, 15 May 2000 10:12:46 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: prolog@swi.psy.uva.nl
References: <Pine.LNX.3.91.1000512175307.18261C-100000@pdev.inet.co.za>
In-Reply-To: <Pine.LNX.3.91.1000512175307.18261C-100000@pdev.inet.co.za>
MIME-Version: 1.0
Message-Id: <00051510355502.06671@gollem>
Content-Transfer-Encoding: 8bit

On Fri, 12 May 2000, Paul Sephton wrote:
>On Thu, 11 May 2000, Paul Singleton wrote:
>
>> Jan Wielemaker wrote:
>> > ...
>> > In general, I would not use strings very often these days.
>> 
>> Is there any good case for using them at all?
>> 
>> Should I feel guilty in making no provision for them in my Java and
>> ODBC interfaces?
>> 
>> Do you envisage "pulling the plug" on them within a few years?
>
>Please excuse the blatherings of an idiot, but:
>
>As far as I can tell, there are presently four distinct ways to represent 
>a "string" in SWI Prolog:
>  1) as an atom- at least that one is understandable
>  2) as a list of integer values
>  3) as a list of single character atoms
>  4) as a string type (afaik internal format).
>
>so, atom_chars/2 converts between #1 and #3
>    atom_codes/2 converts between #1 and #2
>    list_to_string converts between (#2 or #3) and #4
>    string/1 tests for #4 and fails for the rest
>
>I have two uses:
>
>1)  Using #2 or #3 for parsing external data
>
>I have a very good case for using #2 in my implementation of a parser.  
>The input to the parser is a (#2) and the output is a difference list.  
>For some reason or other, the use of #3 rather than #2 breaks the parser, 
>although, to all intents and purposes, these should be transparent...

If you use one-character atoms consistently, it should.  Note however
that "foobar" normally yields codes (see the option double_quotes).

>2) Using #4 for space efficient data storage
>
>My case for the use of #4 is that it goes nowhere near the atom table, 
>and I never search on the information stored as such.  Were one to use 
>atoms to store arbitrary data, would that not lead to degradation in 
>performance?  Storing the information as a list is the alternative, and I 
>have no idea of the overheads there.
>
>Am I incorrect in my assumpton that storing all "string" type information 
>as atoms would lead to a very large global atom table, and thus slow 
>everything down?

Not really.  Storing an atom implies computing the hash-value (which is
linear to the size), try to find the atom (the atom-table is
automatically rehashed if it gets too populated, so this needs a roughly
constant low number of memcmp() calls) and finally allocating and
copying the atom (if it is new).

If we are talking large numbers of long unique atoms the main
additional overhead will be the computation of the hash-key.  Using
atoms rather then strings reduce normal garbage collection activity,
though you get atom garbage collection as a price.  All in all, I
don't think there will be a noticible performance difference on
`normal' applications.  Only applications getting strings from
foreign code, handing them unparsed over the foreign interface and
doing failure-driven control might be significantly faster using
strings rather than atoms.

	Regards --- Jan

