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
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.
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
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
*