From: Bobby Abraham
Subject: Symbols vs Strings
Date: 
Message-ID: <1991Oct09.070245.21898@daisy.ee.und.ac.za>
Some help please, if you would.

I am wanting to improve the performance of an application I have writen.
I have two sets of frames which are stored in a separate hash tables. 
Currently these frames are retrieved on a key which is an interned symbol.

ie (gethash '|Mycotoxin A| *symptoms-hash-table*)
   =>  some-frame

I also test, frequently, whether a key is a member of various lists of other
keys.

What I want to know is what are the advantages/disadvantages of using interned
symbols over strings as key values?

For what is it worth I'm using Golden Common Lisp 3.1 and have about 600
of these frames.

Thank you
- Bobby

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
Bobby Abraham
Dept of Computer Science, University of Natal, Pietermaritzburg
········@daisy.ee.und.ac.za

From: Richard Lynch
Subject: Re: Symbols vs Strings
Date: 
Message-ID: <3559@anaxagoras.ils.nwu.edu>
In article <······················@daisy.ee.und.ac.za> ········@daisy.ee.und.ac.za (Bobby Abraham) writes:

>Some help please, if you would.

>I am wanting to improve the performance of an application I have writen.
>I have two sets of frames which are stored in a separate hash tables. 
>Currently these frames are retrieved on a key which is an interned symbol.

>ie (gethash '|Mycotoxin A| *symptoms-hash-table*)
>   =>  some-frame

>I also test, frequently, whether a key is a member of various lists of other
>keys.

>What I want to know is what are the advantages/disadvantages of using interned
>symbols over strings as key values?

Forgive me if I'm stating the obvious, but make sure you are making an eq
hash-table: (defvar *symptoms-hash-table* (make-hash-table :test #'eq))
[Actually, you may have to us 'eq  instead of #'eq, I forget.]
The default is, I believe, eql.  Thus you may be using a slower hash-function.

Also, if you know in advance what the size of the tables will be (roughly),
you should also provide additional keywords to make-hash-table, :size 600.
This could lead to a speedup during run time if the frames are added
dynamically.

It would surprise me very much if switching to strings and an equal hash-table
-- 
"TANSTAAFL"     ·····@aristotle.ils.nwu.edu
From: Jeff Dalton
Subject: Re: Symbols vs Strings
Date: 
Message-ID: <5401@skye.ed.ac.uk>
In article <······················@daisy.ee.und.ac.za> ········@daisy.ee.und.ac.za (Bobby Abraham) writes:

>I am wanting to improve the performance of an application I have writen.
>I have two sets of frames which are stored in a separate hash tables. 
>Currently these frames are retrieved on a key which is an interned symbol.

>ie (gethash '|Mycotoxin A| *symptoms-hash-table*)
>   =>  some-frame

>I also test, frequently, whether a key is a member of various lists of other
>keys.

Why do you use these keys _at all_?  Why not use the frames directly?
I suspect that in most cases where your approach is used the extra
level of indirection is not needed.
From: Simon Leinen
Subject: Re: Symbols vs Strings
Date: 
Message-ID: <SIMON.91Oct9182918@liasun5.epfl.ch>
In article <······················@daisy.ee.und.ac.za>
········@daisy.ee.und.ac.za (Bobby Abraham) writes:

   I am wanting to improve the performance of an application I have
   writen.  I have two sets of frames which are stored in a separate
   hash tables.  Currently these frames are retrieved on a key which
   is an interned symbol.

   ie (gethash '|Mycotoxin A| *symptoms-hash-table*)
      =>  some-frame

   I also test, frequently, whether a key is a member of various lists
   of other keys.

You should try to separate the presentation and representation levels
completely; internally, always use the objects (symtoms) rather than
their names.  The lists of keys would become lists of objects, and you
could always use #'EQ for comparison.

In general, I do not recommend symbols if you only need the names.  A
symbol usually has a package cell, a value cell, a function cell and a
property list cell, so each symbol weighs about 40 bytes in a typical
CL implementation, plus the characters in the print name.  In
addition, you keep these symbols in a package, so they will usually
not be garbage collected.  I find it more natural to use strings if
you need a flat space of readable names.
-- 
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
From: Len Charest
Subject: Re: Symbols vs Strings
Date: 
Message-ID: <1991Oct10.184725.2671@jpl-devvax.jpl.nasa.gov>
In article <··················@liasun5.epfl.ch>, ·····@liasun2.epfl.ch (Simon Leinen) writes:

> In general, I do not recommend symbols if you only need the names.  A
> symbol usually has a package cell, a value cell, a function cell and a
> property list cell, so each symbol weighs about 40 bytes in a typical
> CL implementation, plus the characters in the print name. 

If memory is that critical to your program then LISP is probably the wrong language to use. Also, symbol-valued keys will be allocated (consed) ONCE, whereas string-valued keys will be consed each time the key is appears textually in the program or is typed by the user.

> In addition, you keep these symbols in a package, so they will usually
> not be garbage collected. 

This is bad? If an object is being referenced (e.g., as a key in a hash table) then it should not be garbage collected. Anyway, IMO in any application its best to use data structures that keep garbage generation to a minimum.
-- 
*
Len Charest, Jr.                                       ·······@ai-cyclops.jpl.nasa.gov
JPL Artificial Intelligence Group
*