Path: utzoo!mnetor!uunet!mcvax!unido!ecrcvax!micha
From: micha@ecrcvax.UUCP (Micha Meier)
Newsgroups: comp.lang.prolog
Subject: Strings
Message-ID: <512@ecrcvax.UUCP>
Date: 11 Mar 88 12:04:28 GMT
Reply-To: micha@ecrcvax.UUCP (Micha Meier)
Organization: ECRC, Munich 81, West Germany
Lines: 43

In Prolog Digest V5.100 Richard O'Keefe writes

"... if efficiency is your concern your are better off using lists
of character codes than strings."

May I ask this to be precised a little bit more? I can't see why is it
faster to handle structured data on the global stack rather than directly
characters - I guess this applies only for special predicates,
e.g. returning all substrings of a string, but even there it's in
no way evident that using lists is faster. Several points to make:

	- when using lists of character codes, each time when
	  the character code or the next element is accessed,
	  it has to be dereferenced and its type must be tested

	- copying a list is certainly slower than copying a string;
	  for strings you might need a fixed size buffer which
	  can complicate the things a little bit of you want
	  strings of arbitrary length, but it is easier to get
	  another buffer than to get another global stack

	- a list item needs at least 8 bytes, a character only one
	  (plus some fixed amount for each string, e.g. length, end or others).
	  If your string is longer than "aa", you need much more space
	  to handle it as a list, consequently more time due to swapping

	- garbage collection is easier for atoms than for strings
	  in the sense that there is only one reference to the name
	  of the atom, namely from the symbol table itself, but to
	  gather all accessible atoms one has to scan the stacks
	  and the program code anyway (unless you want to trail them
	  which is really not faster)

The point whether strings are necessary or not is another one - but
although our system allows atoms of any length, any number of atoms,
and garbage collection of atoms, we still think that having
strings is useful.

Disclaimer:
" I definitely do not try to defend BSI " :-)


--Micha