Re: IRC client for Emacs

[Noah Friedman <friedman@splode.com>]

>    What do you think about providing persistent hashtables, via gdbm or
>    berkeley db? 
>
>It is not completely out of the question, but it sounds awfully
>heavyweight.  Sinc ethis does need to run particularly fast,
>we ought to be able to do something more simpler, using text
>files directly.

The solutions that come to mind involve generating a separate index for
those files and writing the lookup and loading routines in elisp.  This is
ok, but the disadvantages I see to that are:

    * it's another special-purpose API

    * Since the data is plain text, you either have to read the whole file
      into memory to scan for the relevant data, or else generate a
      separate index file.  Index files would need to be regenerated when
      the plain text file changes, so you have to check for this condition
      somewhere.

      The other alternative is to have a separate message per-file, but
      then performance is dependent on the implementation of the
      filesystem.  For example ext2fs has linear directory tables but xfs
      has b-tree indexed tables; so file name resolution on the former,
      especially in large directories, is slower.
  
    * all the routines for lookup and index generation would be in elisp,
      which is slower than adding C calls to gdbm/dbd.

Persistent hashtables might be useful for other things (such as BBDB), so
they seem worth considering for reasons beyond localization.  For
applications which frequently access the same data, they can cache it.
Perhaps that could even be a feature of hashtables which open the diskfile
in read-only mode, but in any case you could just copy values to a
non-persistent hash.