[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IRC client for Emacs

From: Noah Friedman
Subject: Re: IRC client for Emacs
Date: Wed, 21 Aug 2002 19:39:00 -0700 (PDT)

>    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

      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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]