As has already been observed, TCL Arrays are implemented as hash tables,
and it is a quite good implementation. I've done tests with 10K elements
with reasonably good results. This may suit your needs.
One drawback with TCL arrays is if you need persistance -- there is no
way to store the hash table intact to disk and get it back. Array
set/array get will do the job at the cost of reimplementing the hash table
in memory each time it is read in. This might be fine -- test it first.
The next step up would be dbm/gdbm hash table files. Perl has the
nice feature of associating(!) an associative array with a gdbm disk
file, providing much of the speed of an in-memory hash with persistance.
A TCL interface to gdbm should be available. The berkeley db library
has both hash and btree storage, should you need an ordered traverse.
The next step would be an RDBMS like m(y)sql or postgres. I'm not sure
about m(y)sql, but postgres proports to provide both b-tree and hashed
indexes.
There are a lot of possible solutions. My suggestion would be to
first determine exactly what the performance targets are, and then
mock something up with each of the possible choices and see who
wins. Nothing like rapid prototyping to figure out what is really
going on.
Let us know how things turn out.
-- cary
cobrien@access.digex.net
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.